Method and Apparatus for Providing Security to Devices

ABSTRACT

Systems, methods, and apparatus are provided for generating verification data that may be used for validation of a wireless transmit-receive unit (WTRU). The verification data may be generated using a tree structure having protected registers, represented as root nodes, and component measurements, represented as leaf nodes. The verification data may be used to validate the WTRU. The validation may be performed using split-validation, which is a form of validation described that distributes validation tasks between two or more network entities. Subtree certification is also described, wherein a subtree of the tree structure may be certified by a third party.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/611,770, filed Feb. 2, 2015, which is a divisional of U.S. patentapplication Ser. No. 13/582,867, filed Nov. 12, 2012, which is the U.S.national stage of PCT/US2011/027287, filed Mar. 4, 2011, which claimsthe benefit of priority to U.S. Provisional Application No. 61/314,395,filed Mar. 16, 2010, and U.S. Provisional Application No. 61/311,106,filed Mar. 5, 2010, the disclosures of which are incorporated herein byreference in their entireties.

TECHNICAL FIELD

This application is related to providing security to devices.

BACKGROUND

With the advent of machine to machine communications (M2M), applicationsin e-Health, Geo-Tracking, Home Automation and Consumer Devices havebeen enabled. Many such applications require a network operatorequipment to be placed in customer premises. Such equipments and thedevices are subject to malicious attacks. In order to combat suchmalicious attacks, device integrity verification is required for suchcustomer premise based equipment in addition to other forms of deviceprotection including firewall and virus protection.

Several methods have been discussed for device integrity protection.These methods include a secure boot—where a trusted executionenvironment loads and executes the integrity verified softwarecomponents only. But these methods require an unorganized set ofmeasurements that may become cumbersome to manage in case the number ofsuch measurements is very large. Hence what is required are methods andrelated apparatus that help in collecting, classifying and organizingthe measurements to benefit efficient search of components that failintegrity.

SUMMARY

Various techniques for generating verification data are disclosedherein, including a method for generating verification data that may beused for validation of a wireless transmit-receive unit (WTRU). The WTRUmay have one or more components and a secure environment with a numberof secure registers. According to one embodiment, a value may beobtained, for each of a plurality of components of the WTRU,representing a measurement of the component of the WTRU. A measurementlog (ML) may be generated containing a record of the componentmeasurement values and other component-specific data may be stored onthe WTRU. Verification data may be generated from the componentmeasurement values for each component and the verification data may bestored in one or more of the secure registers within the trustedplatform module. The verification data and the ML may be organized intoa tree structure. The secure registers containing the verification datamay define the roots of the tree structure. The ML may define innernodes of the tree structure, and the measurement values contained in theML may define leaves of the tree structure. The tree structure may beformed using a secure extend operation of the secure environment.

According to another embodiment, a value may be obtained representing ameasurement of a component of a WTRU. Verification data may be generatedfrom the measurement value and the verification data may be stored in aregister within a secure environment on the WTRU. The measurement valuemay be stored at a leaf node in a tree structure. One or more extendoperations may be performed within the secure environment to extend thevalue stored in the leaf node to a root node of said tree structure. Theroot node may include the data in the secure register in which thegenerated verification data is stored.

According to another embodiment, a method is described for validatingtree-formed verification data generated by a wireless transmit/receiveunit (WTRU). The tree-formed verification data may include verificationdata elements, a measurement log (ML), and component measurement valuesorganized into a tree structure. The verification data elements maydefine the root nodes of the tree structure. The ML may define innernodes of the tree structure. The component measurement values may defineleaf nodes of the tree structure. The tree-formed verification data maybe received in an organized tree structure. Starting from a verificationdata element at a root of the received tree-formed verification data,the tree structure may be traversed. As part of traversing the treestructure, values at branching nodes and child nodes of the branchingnodes of the received tree structure may be compared to values at thesame node positions of a reference tree. It may then be determinedwhether to validate the WTRU or an individual component of the WTRUbased on the comparison of the node values.

According to another embodiment, a method is described for certifying anode value of a measurement log (ML) generated by a wirelesstransmit/receive unit (WTRU). The values of the ML may be stored asnodes of a tree structure comprising root nodes, inner nodes and leafnodes. An attestation package may be received that indicates a nodevalue to be certified by a subtree certificate authority (SCA). The nodevalue may be recognized as a node value that can be certified by theSCA. A manifest associated with the node value may be created thatincludes validation information associated with the node value. Acertificate for the node value may be created that is configured to bindthe validation information to a secure environment of the WTRU. Thecertificate may be issued with the manifest and provided to the secureenvironment of the WTRU which stores the certificate in its ML.

Other features and aspects of the systems, methods and apparatusdescribed herein will become apparent from the following detaileddescription and the associated drawings.

The foregoing summary, as well as the following detailed description, isbetter understood when read in conjunction with the appended drawings.For the purpose of illustrating the systems, methods, and apparatusdescribed herein, there is shown in the drawings exemplary embodiments;however, the invention is not limited to the specific methods andinstrumentalities disclosed. In the drawings:

FIG. 1 shows an example Long Term Evolution wireless communicationsystem/access network;

FIG. 2 is an example block diagram of the Long Term Evolution wirelesscommunication system of FIG. 1;

FIG. 3 shows a general structure of tree-formed stored measurement logs(SML) and verification data;

FIG. 4 shows an example of an algorithm (algorithm 1) showing treeformation;

FIG. 5 shows a configuration correct at a right edge;

FIG. 6 shows an algorithm (algorithm 2) showing cleanup of an incompletetree;

FIG. 7 shows order formation/tree branching for an incomplete tree ofdepth 3;

FIG. 8 shows maximum capacity arrangement of tree verification datawhere measurement values at leaves are indicated as m;

FIG. 9 shows classification of node configuration in a tree-formed SML;

FIG. 10 an expected fraction of bad inner nodes on a random distributionof 2^(d)f bad leaves for d=16;

FIG. 11 shows a correct configuration of values in every elementarytriangle in the SML tree;

FIG. 12 shows an algorithm 1, for finding the first point of failure ina linearly hash chain;

FIG. 13 shows an example of Huffman's coding tree;

FIG. 14 shows an example of tree pruning;

FIG. 15 illustrates optimal tree-formed verification systemdiagram/system diagram and associated communication;

FIG. 16 illustrates a tree with surrogate child links where softwarecomponents or functionalities indicated by a module utilizes anothermodule;

FIG. 17 shows an algorithm 2—for determining population of the binarytree with metrics;

FIG. 18 shows an algorithm 3—for determining population of the treeusing TPM commands;

FIG. 19 shows an algorithm 4—for determining population of the n-arytree with metrics;

FIG. 20 shows an algorithm 5—for determining population of the binarytree with surrogate child link;

FIG. 21 shows a compare and prune algorithm 6—to determine the nodes andleaves with failed integrity checks;

FIG. 22 show an algorithm-1 showing TPM_reduced_Tree_Verify_Load;

FIG. 23 shows algorithm-2 showing TPM_reduced_Tree_Verify;

FIG. 24a shows algorithm-3 showing TPM_Tree_Node_Verify;

FIG. 24b shows algorithm-4 showing TPM_Reduced Tree_Update;

FIG. 25 shows data categories for PVM;

FIG. 26 shows Subtree certification Protocol for a subtree with roots;

FIG. 27 shows Certificate Subtree Binding;

FIG. 28 shows a left-unbalanced multi-tree structure;

FIG. 29 shows an exemplary embodiment of a tree structure as describedherein;

FIG. 30 a component subtree structure;

FIG. 31 shows a Split-Validation Step 1: Collection of Measurements;

FIG. 32 shows a Split-Validation Step 2: Certification of Subtrees;

FIG. 33 shows a Split-Validation Step 3: Service Connection;

FIG. 34 shows H(e)NB use case for Split-Validation;

FIG. 35 shows H(e)NB blocking access to rogue devices;

FIG. 36 shows an M2M GW grouping devices based on their type, deviceclass, device properties, or connection profile and providing groupcertificates for the device validation trees;

FIG. 37 shows M2M GW P2P Split Validation;

FIG. 38 is a system diagram of an example communications system in whichone or more disclosed embodiments may be implemented;

FIG. 39 is a system diagram of an example wireless transmit/receive unit(WTRU) that may be used within the communications system illustrated inFIG. 38; and

FIG. 40 is a system diagram of an example radio access network and anexample core network that may be used within the communications systemillustrated in FIG. 38.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

When referred to hereafter, the terminology “wireless transmit/receiveunit (WTRU)” includes but is not limited to a user equipment (UE), amobile station, a fixed or mobile subscriber unit, a pager, a cellulartelephone, a personal digital assistant (PDA), a computer, or any othertype of device capable of operating in a wireless environment. Whenreferred to hereafter, the terminology “base station” includes but isnot limited to a Node-B, a site controller, an access point (AP), or anyother type of interfacing device capable of operating in a wirelessenvironment.

Various techniques for generating verification data are disclosedherein, including a method for generating verification data that may beused for validation of a wireless transmit-receive unit (WTRU). The WTRUmay have one or more components and a secure environment with a numberof secure registers. A secure environment may include a secure hardwareand/or software environment that provides a secure executionenvironment. For example, the secure environment may be a trustedplatform module (TPM), a smart card a Universal Integrated Circuit Card(UICC), or any combination thereof. The secure environment may be usedto protect secured functions, such as cryptographic functions forexample, secure resources, such as operation registers for example,memory, random number generators, timers, and/or clocks for example.

According to one embodiment, verification data may be generated byobtaining a value, for each of a plurality of components of the WTRU,representing a measurement of the component of the WTRU. A measurementlog (ML) may be generated containing a record of the componentmeasurement values and other component-specific data may be stored onthe WTRU. Verification data may be generated from the componentmeasurement values for each component and the verification data may bestored in one or more of the secure registers within the trustedplatform module. The verification data and the ML may be organized intoa tree structure. The secure registers containing the verification datamay define the roots of the tree structure. The ML may define innernodes of the tree structure, and the measurement values contained in theML may define leaves of the tree structure. The tree structure may beformed using a secure extend operation of the secure environment.

According to another embodiment, a value may be obtained representing ameasurement of a component of a WTRU. Verification data may be generatedfrom the measurement value and the verification data may be stored in aregister within a secure environment on the WTRU. The measurement valuemay be stored at a leaf node in a tree structure. One or more extendoperations may be performed within the secure environment to extend thevalue stored in the leaf node to a root node of said tree structure. Theroot node may include the data in the secure register in which thegenerated verification data is stored.

According to another embodiment, a method is described for validatingtree-formed verification data generated by a wireless transmit/receiveunit (WTRU). The tree-formed verification data may include verificationdata elements, a measurement log (ML), and component measurement valuesorganized into a tree structure. The verification data elements maydefine the root nodes of the tree structure. The ML may define innernodes of the tree structure. The component measurement values may defineleaf nodes of the tree structure. The tree-formed verification data maybe received in an organized tree structure. Starting from a verificationdata element at a root of the received tree-formed verification data,the tree structure may be traversed. As part of traversing the treestructure, values at branching nodes and child nodes of the branchingnodes of the received tree structure may be compared to values at thesame node positions of a reference tree. It may then be determinedwhether to validate the WTRU or an individual component of the WTRUbased on the comparison of the node values.

According to another embodiment, a method is described for certifying anode value of a measurement log (ML) generated by a wirelesstransmit/receive unit (WTRU). The values of the ML may be stored asnodes of a tree structure comprising root nodes, inner nodes and leafnodes. An attestation package may be received that indicates a nodevalue to be certified by a subtree certificate authority (SCA). The nodevalue may be recognized as a node value that can be certified by theSCA. A manifest associated with the node value may be created thatincludes validation information associated with the node value. Acertificate for the node value may be created that is configured to bindthe validation information to a secure environment of the WTRU. Thecertificate may be issued with the manifest and provided to the secureenvironment of the WTRU which stores the certificate in its ML.

Structured validation is a validation methodology where the data and theoperational aspects of validation are structured. Separate but relatedconcepts and methods of structured validation are described herein. Forexample, Tree-formed Validation (TFV) is described herein, with a focuson a method that uses subtree certification; extensions and variants ofTFV, and Split validation, where validation tasks are distributedbetween two or more networked entities which allows the network entitiesto perform device integrity validation for (connected) devices in adistributed manner such that each validating entity may not necessarilyhave to validate the whole device but may validate parts thereof.

FIG. 1 shows a Long Term Evolution (LTE) wireless communicationsystem/access network 400 that includes an Evolved-Universal TerrestrialRadio Access Network (E-UTRAN) 605. The E-UTRAN 605 includes a WTRU 610and several evolved Node-Bs, (eNBs) 620. The WTRU 610 is incommunication with an eNB 620. The eNBs 620 interface with each otherusing an X2 interface. Each of the eNBs 620 interfaces with a MobilityManagement Entity (MME)/Serving Gateway (S-GW) 630 through an S1interface. Although a single WTRU 610 and three eNBs 620 are shown inFIG. 1, it should be apparent that any combination of wireless and wireddevices may be included in the wireless communication system accessnetwork 600.

FIG. 2 is an example block diagram of an LTE wireless communicationsystem 500 including the WTRU 610, the eNB 620, and the MME/S-GW 630. Asshown in FIG. 2, the WTRU 610, the eNB 620 and the MME/S-GW 630 areconfigured to perform a method for providing security to devices.

In addition to the components that may be found in a typical WTRU, theWTRU 610 includes a processor 716 with an optional linked memory 722, atleast one transceiver 714, an optional battery 720, and an antenna 718.The processor 716 is configured to perform a method for providingsecurity to devices.

The transceiver 714 is in communication with the processor 716 and theantenna 718 to facilitate the transmission and reception of wirelesscommunications. In case a battery 720 is used in the WTRU 610, it powersthe transceiver 714 and the processor 716.

In addition to the components that may be found in a typical eNB, theeNB 620 includes a processor 717 with an optional linked memory 715,transceivers 719, and antennas 721. The processor 717 is configured toperform a method for providing security to devices. The transceivers 719are in communication with the processor 717 and antennas 721 tofacilitate the transmission and reception of wireless communications.The eNB 620 is connected to the Mobility Management Entity/ServingGateway (MME/S-GW) 630 which includes a processor 733 with an optionallinked memory 734.

Generally, to ensure device integrity, a measurement (such as acryptographic hash value for example) of the software/firmware or of thehardware is performed and compared against a trusted reference value.This comparison of the measurement or any function or grouping of suchmeasurements (known as verification data) against the trusted referencevalue(s) may be performed in the device internally (autonomousvalidation) or externally by a validation entity (semi-autonomous orremote validation). In case of semi-autonomous and remote validation,measurements may be sent as an unorganized set in a payload which may beencrypted, integrity protected and cryptographically certified.

To find the component that failed the integrity verification, acomparison of the set of measurement to the set of reference values maybe done resulting in the set of indices that have failed the integritymeasurement. However, such an unorganized set of measurements may becumbersome to manage if the number of such measurements is very large.

To optimize the search of the failed integrity check module, theverification data may be generated in the form of a hash tree ofmeasurement logs, such as stored measurement logs (SMLs) for example.The term SML, which is used by the Trusted Computing Group (TCG)architecture and specifications, may be used in describing variousembodiments of the measurement log described herein, however SML is oneexemplary embodiment of a measurement log. One example of anorganization is Tree-Formed Validation (TFV). The stored measurement logmay be organized into a balanced binary tree and algorithms may bepresented to generate the tree using TPM commands. The algorithm may begeneric and may be extended to balanced binary trees. The SML arisingfrom tree-formed verification may be similar to the TCG SML in itscontent, but may be constructed, formed, computed, used, stored,retrieved, updated, deleted, transmitted, and/or received incommunication, or otherwise processed or manipulated, differently thanhow a TCG SML may be processed and/or manipulated.

TFV may be implemented in a TrE, such as described below for example. Itgives rise to many other, use-case type, innovations and is a referenceenabler for the complex types of network-side platform validation, whichTrE aims at. The technical content of TFV is described herein. A summaryof TFV pointing is described herein. TFV is also put in the context ofTrE and its application is described herein.

One element of TFV is a hierarchical structure for verification data,which brings along various benefits for platform validation by a remotevalidator. Algorithms are described herein for the creation andmanagement of tree-formed verification data. Furthermore, attestation tosubstructures, i.e., subtrees of verification data, of a platform, maybe used to validate a platform in TFV. The topmost level of verificationdata in the hierarchy, called the (set of) roots, may be protected inTFV, such as by verification data registers with special, e.g.,hardware, protection for example. TFV may operate by small, efficientalgorithms on tree-formed verification data. A whole implementation ofTFV may be implemented inside a TCB, or even a hardware-protected secureexecution environment. Complex structures of validation data may beassociated to and/or protected by the tree hierarchy of tree-formedverification data. Sub-trees may provide inherent semantics toverification and validation data by the structure-substructure relation.Subtrees may therefore identify functional parts of a platform to avalidator.

One embodiment of TFV may use a modified TPM. Trusted Computing as anexisting technology is a potential entry point toward realization and/orstandardization of TFV. TFV also generalizes readily from trees, such asbinary trees, to more general structures that have substructures.

Described below are elements that may be provided by TFV.

Security: Hardware protection is provided in TFV, by protecting theroots of tree-formed validation data. The reference protection level isthat of PCRs in a TPM, and it is shown that this may be maintained byTFV. Small algorithms and low complexity on the platform side enableimplementation on a small TCB, or on-chip.

Management: TFV includes a method and apparatus to reliably and securelysingle out a substructure of a platform and manage the platform based onsuch a collection of substructures. Modules represented by a TFV subtreecan be flexibly changed, updated, or even moved between platforms, withsecurity properties as required by any scenario.

Distribution: The hierarchy of TFV allows for a hierarchical split ofvalidation between entities. This enables more flexible design ofcommunication scenarios and use cases, and also benefits efficiency.

Efficiency: One efficient data structure for searches—binary trees—maybe implemented in TFV. It is shown that, for example, the search forfailed components (with undesired integrity measurement values) may bemore efficient in TFV than in TCG-like platform attestation. The naturalhierarchy introduced by TFV provides the option of load distribution invalidation processes.

One exemplary feature of TFV is that TFV may be designed, by itsbuilt-in hierarchical order, for the validation of a large number oflow-capability platforms by “more central” entities. Thus, TFV may besuited for devices connecting to gateways, and/or via gateways tonetworks. One exemplary use case may include an M2M communicationscenario. This trait of TFV may render it an orthogonal concept to themany existing concepts to provide more semantics to state attestation bya trusted platform. Other approaches to platform attestation show quitethe opposite philosophy. They are suited to platforms capable ofproducing complex validation data, but are not assuming much of ahierarchical, modular structure of it. TFV may be combined with other,orthogonal approaches such as PBA, semantic attestation, virtualization,and/or HIM.

A glossary and list of acronyms used in the description is providedbelow.

RIM Reference Integrity Metric(s) provide reference values to whichactual measurement data can be compared. A RIM is, for the purpose ofvalidation, the counterpart of the measured values provided by a device.They serve as reference for comparison of desired target values withreported measurement values. RIMs provide proof of integrity in thesense that they uniquely are associated with a component, for instanceas cryptographic digest values of component code, obtained in a securetesting facility. They are a metric in the sense that they allow fordirect (deterministic) comparison with measured values.

RIM certificates: A RIM certificate contains a RIM for a specificcomponent, signed by a TTP.

AuV Autonomous Validation.

IDS Intrusion Detection System.

DoS Denial-of-service (attack).

PVM Platform Validation and Management: The combination of platformvalidation by PVE and OTA management of a platform by an (e)HMS.Comprises all potential combined functionality that can be derived fromthe combination.

DMS Device Management System: A generalization notation (3GPP LTE) forthe Home(e)NodeB Management System (HMS) (TS 32.583, [4]), applying togeneral devices and enhanced by PVM functions.

RIM Manager/Manager RIMman: The entity managing the validation databaseV_DB. It is the only entity authorized to do that and the only one whichcryptographically operates on digital certificates (verification,generation).

SAV Semi-autonomous validation. The validation variant PVM is based on.

TCG Trusted Computing Group.

TSS Trusted Software Stack.

TPM Trusted Platform Module

TTP Trusted Third Party.

TCB Trusted Computing Base. The part of a system which cannot beassessed for trustworthiness at runtime and therefore must beunconditionally trusted.

CN Operator Core Network.

SHO Selected Home Operator.

PKI Public Key infrastructure.

PDP Policy Decision Point.

PEP Policy Enforcement Point.

D-H Diffie-Hellman.

TFV Tree-Formed Validation.

Verification data: Data uniquely identifying the total outcome of theinternal verification in a secure start-up process. Prime examples arePCR values, i.e., digests, in form of chained hash values, of amultitude of measurement values.

Validation data: In distinction to verification data, validation data isall data that is submitted to another party, the validator, and used toassess the trustworthiness of the state of the platform.

Validation: The process of submission of validation data to thevalidator, for instance realized as remote attestation according to TCG,and evaluation thereof by the validator, is properly called validation.Validation data may often comprise verification data such as quotedverification data register (e.g., PCR) values. Validation may, beyondcryptographic verification of verification data, include policyevaluation and triggering of actions by the validator.

Verification data register: Hardware storage protecting verificationdata against unauthorized access and change.

The establishment of trust relationships to a trusted platform relies onthe process of validation. Validation allows an external entity to buildtrust in the expected behavior of the platform based on providedevidence of the platform's configuration. In a validation mechanism suchas remote attestation, the trusted platform exhibits verification datacreated during a start up process. These data may be hardware-protectedvalues of platform configuration registers, containing nestedmeasurement values, such as hash values for example, of all loaded orstarted components. The values may be created in linear order by thesecured extend operation. Fine-grained diagnosis of components by thevalidator, based on the linear order of verification data and associatedmeasurement logs, may be inefficient. A method to create a tree-formedverification data is provided, in which component measurement valuesrepresent leaves and protected registers represent roots. Thefunctioning of this method is shown using a limited number of hardwareprotected registers and the standard extend operation. In this way, thesecurity of verification data may be maintained, while the storedmeasurement log may be consistently organized as a tree. The basicmechanism of validating a platform using tree-formed measurement logsand verification data is discussed.

The process of building trust in computing platforms may follow aunique, common pattern. During start up of the platform, components maybe measured by a protected entity on the platform. For example, thecomponents may be measured before they are loaded and/or executed. Thegeneration of a chain of trust is an important concept for a TrustedComputing System. This chain may extend without gaps from system boot upto the current system state, including executed instructions andprograms. Each component may be required to measure and report thefollowing component before executing it. Measurement of the directsuccessor may prevent unmonitored execution of code between measurementand actual execution. The measurement process may be protected by theroot of trust for measurement, and may be implemented for instance bycomputing a digest value over code and configuration data.

Verification data may be compiled from the measurement values by aprotected operation and/or stored in protected storage. The verificationdata may identify, such as after completion of secure start up, theplatform's state uniquely. Embodiments of these processes may beauthenticated and secure boot specified by the Trusted Computing Group(TCG). Authenticated boot may used for PC clients. Secure boot formobile platforms may also be used. The difference between the two may bethat secure boot adds a local verification and enforcement engine thatlets components start if their measurements are equal to trustedreference values.

TCG proposes to compute verification data via the extend operation ofthe Trusted Platform Module (TPM), respectively, the Mobile TrustedModule (MTM), from measurement values, which are hashes of componentcode and/or data. The data may be stored in Platform ConfigurationRegisters (PCRs). As an example, a minimum of 16 PCRs may existaccording to version 1.1 of the specification and at least 24 PCRs maybe identified in version 1.2 in the TPM. The PCRs may be accessed byauthorized commands. The extend operation builds a linearly ordered,nested chain of hash values, akin to the Merkle-Damgård transform, asfollows:

V _(i) ←V _(i) ⋄mdefH(V _(i) ∥m),  (Equation 1),

where V_(i) denotes a verification data register (i=0, : : : , 23 forPCRs), H is a collision-resistant hash function (SHA-1 in case of theTPM), and m=H (data) is a measurement value. Thus, verification data ofa TCG trusted platform may be secured against manipulation by the TPM'sprotected functions and shielded capabilities.

The verification data may be accompanied by a more expressive record ofmeasurement values and/or other component-specific data in the storedmeasurement log (SML). In validation toward an external entity,verification and/or other data, such as the SML, may be signed by theplatform and transferred to the validator. The validator may be able toassess the trustworthiness of the platform to any desired granularity,which may be limited by the total information conveyed duringvalidation. Paradigmatic embodiments for validation may be defined bythe TCG in the attestation protocols. It is envisaged by TCG, thatvalidation may eventually be used to take remedial steps on trustedplatforms, for example upon first network or service access, asenvisioned by the Trusted Network Connect working group of the TCG.

A method to organize verification data and SML differently from thelinear order foreseen by TCG specifications, in a tree (such as a Merklehash tree for example), is provided. The efficiency problem withlinearly chained verification data is highlighted from the viewpoint ofapplications. The central security problem in organizing verificationdata as a tree is to make their generation as secure as themeasurement-extend operations of TCG specifications is also provided. Amethod and algorithm to generate verification data in a limited set ofhardware protected registers, which truthfully represents the root nodesof a hash tree is also provided. It is also shown how tree-likeverification data and SML can efficiently and effectively be used forvalidation. Implementation options for tree-formed verification data andthe experiments performed are also discussed.

Verification data provides information about a systems state withunconditional security. For example, they may be secure independently ofthe SML, which, according to TCG standards, may have no particularprotection on the platform or in a validation (it may not be part of thesigned attestation data). The signed PCR values, i.e., verification dataitself, may provide an implicit integrity control for the SML. For this,the verification data may be recalculated from the measurements in theSML, by retracing all extend operations.

The TCG-standardized way to use PCR values in authenticated boot tosecure the measurement log may be based on the technique introduced bySchneier and Kelsey for securing audit logs on untrusted machines. Infact, it may be a simplification, since the last element of the hashchain is kept in a PCR, while the SML may contain the measurement valuesand not the intermediate entries of the hash chain. Integritymeasurement using the TPM may be implemented in the IntegrityMeasurement Architecture (IMA) as a Linux kernel module to measure theintegrity using the TPM and to generate a linear SML.

Verification data, created by linearly chaining extend operations, maybe of limited value for remote diagnostics of a platform, and/oradvanced management such as component-wise remediation. Essentially, theposition of a manipulation of the SML, either by tampering with ameasurement value before it is extended into a PCR, or by tampering withthe SML itself after secure start up, may not be localized withcertainty. Furthermore, the space complexity of real world SMLs withmany hundreds, or thousands, of measured components, may make sifting itthrough for components which fail validation, i.e., for whichmeasurement value differs from a “good” reference value, costly. Forchecking of code and/or data there may be a variety of cryptographicchecksum functions available, and they may require that the integrity ofthe checksums for the “correct” data be maintained. The requirement fora centralized database of software in valid versions on the variousmachines may be a significant management problem, in need of anefficient solution. Future, large scale deployments of networkeddevices, such as required in machine-to-machine communication scenariosfor example, may require a solid device and network-side, balanced andefficient trust infrastructure. Security requirements may be high fordevices loosely connected to networks and operating semi-autonomously.Scenarios considered by the industry, may entail a high-levelrequirement for remote integrity check, or validation, of a connectingdevice. Methods and apparatus described herein may be used to makevalidation expressive, efficient, and/or secure.

The specifications of the TCG Infrastructure working group may includean approach to this problem, hierarchically distinguishing betweenverified components and sub-components. A Tree of Trust (ToT) conceptand notation is described that represents a platform's structure. AToT's nodes may represent platform components, from TPM up toapplications, annotated with trust and security statements. It may beused to assess the trust that should be put into the platform, or evento reorganize the platform according to certain constraints.

Another technical domain where the shortcomings of a merely linear chainof trust becomes imminent is virtualization. Virtual machines may becreated and/or destroyed dynamically on potentially many layers,resulting in a tree-like, dynamic structure of trust dependencies. Whilethe community may have acknowledged that structured validation data maybe required to truly assess platforms' trustworthiness, a granularassociation of such tree-formed data hierarchies to verification data(PCR values) may be lacking.

The verification data and SML may be organized into a binary treestructure. In such a structure, verification data registers are theroots, the SML data structure may include the inner nodes, and theleaves may be the component measurement values. The whole structure maybe a tree form, such as a representative of the class of Merkle hashtrees for example. The method may be generalized to n-ary and arbitrarytrees. The Christmas tree of FIG. 3 is used to show the general conceptof tree-formed verification.

FIG. 3 shows a general structure of tree-formed SML and according toverification data. The star represents the root of the tree stored in averification data register. Components (code and/or data) are indicatedby packets at the leaves. Measurements hashes of the components areindicated by slip knots. Inner nodes (balls) transport verificationinformation upstream to the root. The lines hint at the traversal of thetree for validation, explained in more detail later.

Secure creation of verification data which represents root nodes of hashtrees may pose a problem. In the normal extend operation, themeasurement value taken by the Root of Trust for Measurement (RoTM) on acomponent, and the current verification data register value V_(i) areused, and the operation itself is carried out in the hardware protectedTPM.

Thus, in particular, measurements stored without protection in the SML,are not used in the generation process. This may not be possible for ahash tree, where adding a new leaf may affect d−2 inner nodes of thetree, where d is the tree's depth. The challenge may be to generatetree-formed verification data inside a limited number of hardwareprotected registers (PCRs), such as by using a single leaf measurementvalue as input, and employing the TPM extend operation and other TPMcapabilities.

It may be clear from the minimal requirements required on a systemcreating and protecting tree-formed verification data, that the methodsand apparatus in the following description may not be restricted toplatforms and secure hardware elements adhering to TCG standards.

Verification of programs may be performed before loading and whilebooting. Attestation may also be used as described herein. Codeauthentication is among the goals of Trusted Computing. Executed codemay be protected by securing start up of a platform. For example,hardware mechanisms may be used to bootstrap trust in the host withsecure coprocessors on standard PC hardware. Trusted platforms may beapplied. Secure hardware may be involved in the secure bootstrapprocess. For instance, a secure coprocessor may halt the boot process ifit detects an anomaly. This assumes that the bootstrap ROM is secure. Toensure this, the system's address space may be configured such that theboot vector and the boot code are provided by a secure coprocessordirectly or the boot ROM itself could be a piece of secure hardware.

Regardless, a secure coprocessor verifies the system software (OSkernel, system related user-level software) by checking the software'ssignature against known values. Tamper resistance of code may beimplemented in this process. One approach to the problem may be rootingtrust for program execution in hardware, such as the XOM (eXecute OnlyMemory) processor architecture for example, and the XOM Operating Systembuilding on it. This may not solve the problems of secure loading aprogram, and/or attesting to external entities. AEGIS uses secure booton a PC. For example, AEGIS uses a signed hash to identify each layer inthe boot process, as does Terra, which may attest loaded components witha complete chain of certificates ending in attestation of virtualmachines.

TCG specifications define a bi-lateral remote attestation to verify theintegrity of a platform remotely, by verifying the binary executables.Executed code may be measured when it gets loaded. The measurements maybe stored in PCRs as verification data, and the TPM may attest to thesedata by signing them with a TPM protected key. The verifier may, uponreceipt of these metrics, decide if the platform may be consideredtrustworthy. Since the configuration may be transmitted and verified,the verifier may to know the configurations of the machines.Furthermore, binary attestation discloses the configuration and thusposes a privacy risk. In different solutions, “property,” and“property-based attestation” (PBA) are discussed. PBA allows assuringthe verifier of security properties of the verified platform withoutrevealing detailed configuration data. A trusted third party (TTP) isused to issue a certificate which maps the platforms configuration tothe properties (in particular desired/undesired functionality) which canbe fulfilled in this configuration. The TPM may then, using azero-knowledge proof, attest these properties to the verifier withoutdisclosing the complete configuration.

PBA moves the infrastructural problem of platform validation to a TTP,similarly to, but extending the role of, the TCG's privacy certificateauthority (CA). Another alternative is presented by the Nexus OS whichbuilds on a minimal Trusted Computing Base (TCB) to establish strongisolation between user space and privileged programs. Nexus has securememory regions and monitoring and enforcement machines to protect them.One application may be to move device drivers into user space.Attestation by Nexus attaches descriptive labels to monitored programsand thus allows for expressiveness similar to PBA, but system immanent.Both the PBA concept, as well as the Nexus approach do not have means tovalidate a complex system comprised of a multitude of components, whichfurthermore shall be dynamically managed. Both approaches are orthogonalto the present one, and could be combined with it.

Hierarchical Integrity Management (HIM), presents a dynamical frameworkfor component-wise integrity measurement and policy-enabled managementof platform components. Components and sub-components are related in HIMvia dependency graphs, the most general structure that is useful forthis purpose. But HIM is not aimed at remote platform validation anddoes not protect structured platform verification data in a PCR. Rather,it holds measurements are together in a global Component ConfigurationRegister (software registers) table.

One application of the hash trees, such as the hash trees introduced byMerkle for example, for integrity protection of large datasets may be incertificate management in a PKI. This may yields long-termaccountability of CAs, using tree structures such as Merkle trees, orauthenticated search trees. The use of hash trees may be extended togeneral long-term secure archiving for digital data. Hash trees may beused for run-time memory protection.

A system may employ hash trees for storage and/or memory protection andmay be separated into untrusted storage and a TCB. A program running onthe TCB may use hash trees to maintain the integrity of data stored onan untrusted storage, which may be, e.g., an easily accessible, bulkstore in which the program regularly stores and loads data which doesnot fit into the TCB. The root of the entire tree may be stored in anon-chip trusted register of constant size, but other nodes may be storedin main memory or cache. Another use of hash trees may include where itis shown how they may support authentication of distributed code inWireless Sensor Networks (WSN). Also in WSN, data aggregation involvingmultiple nodes may be integrity protected using hash trees.

Another embodiment to make verification data searchable may includeAuthenticated Append-only Skip Lists, which may be sorted linked listsdesigned to allow fast lookup of the stored data elements by taking“shortcuts.”

However, trees may be better suited for validation of a platform'sstate, such as to efficiently determine the subset of components at theleaves failing validation for example. Systems, methods, and apparatusare described herein for generating a tree structure, such as a binaryMerkle tree for example, from component measurement values using alimited set of tamper-resistant verification data registers. The treestructure may be generated using the capabilities of a TPM, such as thestandard extend operation for example. The algorithm may be small enoughto be executed within a TCB, in particular on-chip. This part of themethod may increase security of the generation of the root of a hashtree, which in turn may provide more security to the tree nodes. Alsodescribed herein are systems, methods, and apparatus for exploiting thetree structure for efficient validation with enhanced diagnosticcapabilities over common PCR values and SMLs, to increase securityfeatures of remote platform validation, and concurrently benefiting fromthe efficiency of tree-like structures in the search for failure points.This use of tree structured data may be used for secure diagnostics,validation, and/or attestation.

The systems, methods, and apparatus described herein may use a limitednumber of verification data registers to securely generate one rootverification value. Each reference to the concrete embodiments ofTrusted Computing specified by the TCG, such as the TPM operations,PCRs, and/or SML for example, may be exemplary embodiments used inimplementation of the systems, methods, and apparatus described herein.The algorithms and/or procedures may be applied to each securitytechnology with the minimum capabilities which are used by them.

One of the hardware protected registers, v def {V₁, . . . , V_(r)} e.g.,PCRs, may include the root of the final tree. The tree may be binary, tokeep the algorithm compact and to provide a fine grained detection offailed components for example. The leaves may carry the measurementvalues, while the inner nodes may be stored in a modified SML. The SMLmay be modified in a way to support the tree structure of the validationdata, i.e. it may not be a linear list of measurement values but thedata structure may support standard tree operations and traversals. Forefficient search during platform validation, the SML may support theaddition of new leaves and retain edge relations. Adding a newmeasurement at a leaf to the tree at depth d may require recalculationof d−1 inner nodes of the leafs reduced hash tree and/or the tree rootwhich is stored in a Vεv. A Merkle tree has a natural coloring of edgesas “left”, respectively, “right” ones, since the binary extend operation(1), is non-commutative. Leaves inherit this order and are added fromleft to right. The binary, d-digit representation of leaf n,0≦n≦2^(d)−1, denoted by

n

, yields natural coordinates for the inner nodes and edges on the uniquepath from leaf to root. That is, the kth digit (counted from the MSB,k=1, . . . , d),

n

_(k)=1, determines whether the node at depth k−1 on this path isconnected by a left, respectively, a right edge, by

n

_(k)=0, or

n

_(k)=1, respectively.

The root of each subtree created during the execution of the algorithmmay be stored securely in a Vεv. If two subtrees (measurement values aresubtrees of depth 0) with the same depth d′ exist, they may be merged toa single tree of depth d′+1. In using the merge operation, one of thetwo V protecting the roots of the subtrees may be freed after the mergeoperation. The update algorithm for a newly arriving measurement valuemay be formulated such that registers V₁, . . . V_(d-1) contain thecurrent state of “active” subtrees of depth 1, . . . , d−1, and thusV_(d) may contain the current global root value.

“Active” here may be described as a subtree, the root of which awaitscompletion by merging with a subtree of the same depth. Care is taken inthe formulation so that the actual measurement value, protectedregisters, and/or the normal extend operation are used, and nounprotected memory places are involved. Denote an empty node in the fullbinary tree of depth d by nil. The tree formation may be performed byAlgorithm 1 as shown in FIG. 4.

The various operations involved in algorithm 1 include:

M Add measurement to V_(d); V_(d←)m.

S_(V) Store a verification data register to SML; V_(k)→SML.

S_(m) Store measurement to SML; m→SML.

V Copy verification data register; V_(k←)V_(k+1).

E1 Extend V_(d) with measurement; V_(d←)V_(d)⋄m.

E2 Extend inner node registers; V_(k←)V_(k)⋄V_(k+1).

The symbols above denote the operations and their execution timesinterchangeably. The one missing operation m_(←)RoTM may be subsumed inS_(m).

If n<2^(d), the tree may be incomplete at the right edge, and thecleanup procedure shown in Algorithm 2 as shown in FIG. 6 may beimplemented.

Algorithm 2 (FIG. 6) may result in a final merge of roots such that V₁ultimately contains all the subtree information. This cleanup proceduremay be reached if the tree is not already full, due to the test in lines17-21 of Algorithm 1 as shown in FIG. 4. The rule by which the tree iscompleted is that the configuration, as shown in FIG. 5, is correct atthe right edge.

Inner nodes may be written to the SML, even if they are the result offorwarding along a left edge (entailing minor redundancy). Formally, theabove rule by which the tree is completed may be interpreted asmodifying the notion of the ‘⋄’ operation such that x⋄nil=x, asexplained herein.

If leafs and inner nodes are appended to the SML in the order prescribedby Algorithm 1 as shown in FIG. 4, a natural serialization of theresulting tree may be obtained. This order is shown in FIG. 7 for anincomplete tree of depth 3.

In FIG. 7, marked entries 10 and 11 in the resulting SML are identical,since 11 is created by a forward operation of the cleanup Algorithm 2.The SML order can be used to address tree nodes in the SML by a binarysearch. Given a sequence number K in the SML of length 2^(d+1)−1, such asearch proceeds from the root, which is the last entry. The remaining2^(d+1)−2 entries are equally partitioned into portions of size 2^(d)−1,and it is decided if K is in the left or right part. This procedure isiterated until K points to the rightmost element in the current part.The sequence of decisions made yields the sequence of left-right edgesleading from the root to the node with index K in the SML.

The tree-formation Algorithm 1 of FIG. 4 may easily be adapted to treesof arbitrary, uniform, arity (the arity of a function or operation isthe number of arguments or operands that the function takes), such as b.For this, the binary coordinate

n

has to be replaced by the b-ary coordinate

n

^((b)) and its d-th, respectively, k-th digit evaluated in line 4,respectively, 12 of algorithm 1 as shown in FIG. 4, where the evaluatedexpression has to be changed to

${{\langle n\rangle}\frac{(b)}{d}} = {b - 1.}$

Algorithm 2 (FIG. 6) may be adapted accordingly. A furthergeneralization to arbitrary trees may require establishment of theassociated node coordinates, i.e., of the mapping n→node. At each nodewith arity higher than 2, since hash extension is linear for the legsconnecting to it, the disadvantages mentioned above may apply, and lossof detection granularity may occur.

It is clear from the generation procedure that, with a limited number,V₁, . . . V_(r), of verification data registers, a finite number ofcomponents at the leaves of trees may be covered. The maximum capacitymay be calculated as follows. The procedure for the first register, V₁,may use the r−1 other registers as a pipeline of length r−1 to build atree of depth r. When V₁ is occupied, the second register may support atree of depth r−1, and so on, until the last register, V_(r), for whichthe pipeline has length 0 and the tree depth 1. Thus the total number ofleaves carried by the trees of the registers may be given by:

$\begin{matrix}{{C_{trees}{\sum\limits_{k = 1}^{r}\; 2^{k}}} = {2^{r + 1} - 2}} & \left( {{Equation}\mspace{14mu} 2} \right)\end{matrix}$

For r=24, the number of PCRs of a TPM adherent to the v 1.2specification, this yields 33, 554, 430 places for componentmeasurements at the leaves of the r trees. If restricted to the last 16PCRs, since, for instance, according to the PC Client specification ofthe TCG, PCRs 0-7 are reserved, and the specification still counts 131,070 measurements. Though this capacity is high, it is not limitless, asthe standard is linear extendible. Thus, since the number ofmeasurements to be taken during start up or at run-time is not a prioriknown, the last register may, as a fallback, be linearly extended afterthe capacity limit is reached. FIG. 8 shows this arrangement-showingmaximum capacity arrangement of tree verification data. In FIG. 8,measurement values at the leaves are indicated as m.

The spatial complexity of the tree formation algorithm is very small. Asinternal data needs precisely three: dε{1, . . . r}, nε{0, . . .2^(d)−1), and kε{1, . . . d}, the size of that data is at most d+2┌log₂d┐≦r+2┌log₂ r┐d bits.

Additionally, depending on implementation one register may be requiredto receive and hold the current measurement value, and/or asintermediate register for the operations on verification data registers.The SML increases moderately in size. For a completely filled binarytree of depth d,2^(d+1)−2 node values, including leaf measurements, arestored in the SML (the root node is contained in a V_(i)). That is, thetree-formed SML is less than double the size of the linearly formed SMLcontaining only measurement values.

For an estimation of the temporal complexity, a full tree of depth d,i.e., 2^(d) leaf measurements is considered. By the structure of thetree, the occurrences of the operations may be counted. S_(m). occurs ateach leaf, i.e., 2^(d) times. E1 and M occur at each inner node at depthd−1, i.e., 2^(d+1) times. V and E2 occur at each inner node from depthd−2, upward, i.e., 2^(d+1)−1 times. Finally, Sv occurs at each innernode of the tree except the root, which remains in V₁. That is, S_(v)occurs 2^(d)−2 times. Altogether this yields the estimate: 2^(d+1)(E₁+M)+(2^(d+1)−1)(V+E²)+2^(d)S_(m)+(2^(d)−2)S_(v) for the algorithm'sexecution time, disregarding flow control. Grouping similar operations{E₁, E₂}, {M, S_(v), S_(m)} yields2^(d+1)(E₁+E₂)−E₂+2^(d+1)(M+2S_(v)+2S_(m))−2S_(v)+(2^(d+1)−1)V.

Assuming that memory operations are approximately equally time-consumingand bounded by a common constant

${M \approx {Sv} \approx {\,^{\frac{1}{2}}{Sm}} \approx {\,^{\frac{1}{2}}V} \leq S},$

where a factor 2 is included in V for a naïve read/store implementation,and in Sm for the missing operation mentioned above, and likewise forthe extend operations E1≈E2≦E, a coarse estimate for the temporalcomplexity of tree formation for d>1 is given by

$\leq {{2{d\left( {E + {4^{\frac{1}{2}}S}} \right)}} - {\left( {E + {4S}} \right).}}$

When extend operations are the dominating factor, tree formation mayneed one extend operation less than the linear chain of authenticatedboot.

For the validation of tree-formed verification data, generated by theprocedure as described above, a validation strategy that exploitsavailable information at each tree node is described. The averagecomputational cost may be calculated in relation to the number,respectively, relative share of failed measurements.

Taking a linear chain of measurements generated and stored in anordinary authenticated boot and sequentially extended to a PCR as thereference case, it is seen that tree traversal validation issignificantly different. In the former case, a manipulation of the SMLmay not be localized in principle, while traversing a tree-formed SMLmay allow identification of a subtree where a manipulation has occurred.Similar considerations hold for diagnostic validation, i.e., the searchfor components which do not conform to a desired reference configurationof the validated platform (described as failed components herein). Forthe linear chained SML this may require comparing each measurement witha reference value and/or recalculating the chain of extend operations upto the PCR to verify the SML's integrity. Since manipulations in thelinear SML may not be localized, a failure to reproduce the PCR valuemay mean that diagnostic validation may not be possible, and failedcomponents may not be distinguished from good ones.

For tree-formed SML, the situation is much better. If a subtree isidentified, where manipulation of the SML is suspected, the complementof it in the SML tree may still be validated. Also, for diagnosticvalidation, one may expect a significant speed-up in determining the setof failed components, and concurrently verifying the root verificationdata register contents.

The validation of a tree-formed SML may be used to find the subset ofleaves failing validation, and/or to detect manipulations of the SML,where possible. It may be assumed that there is a reference tree forcomparison locally available at the validator. Validation may start fromthe root of the tree, i.e., a verification data element V, traversingthe tree of SML data. This may yield the leaf set of components forwhich measurements differ from reference values, called failedcomponents. In traversing the tree, a depth-first search with pruningmay be applied, and decisions may be taken at every branching node. Thetrees may be binary. The SML tree values at a branching node and its twochildren may be compared with the reference tree values of the same nodepositions, and the results may be noted as g (good) for agreement and/orb (bad) for discrepancy. In this notation, the following situations mayoccur, as shown in FIG. 9. FIG. 9 shows classification of nodeconfigurations in a tree-formed SML.

In FIG. 9, in case (a), the whole subtree below this parent node may bevalidated positively, and traversal may end at this node. In FIG. 9, incase (b), the parent node may be recalculated by the validator applyingthe extend operation to the child node values. If the recalculated valuedoes not match the value at the parent node, this may indicate a SMLmanipulation in one of the subtrees with a root marked as bad. This maybe handled as an exception.

Otherwise, validation may proceed to the next tree level, traversing thesubtrees where bad values are found, i.e., left, right, or both subtreesin (b), respectively. In cases (c), a tree manipulation exception may bedetected. This detection may take place without recalculating an extendoperation. The last situation, (d), may occur when the binary tree isincomplete, and/or a right branch is null. Then value x may equal valuey, in which case traversal may proceed to the left, and otherwise a treemanipulation exception may occur.

One advantage of validating tree-formed SMLs is that subtrees with acorrect root may be discarded from further search for failed components.A simple, probabilistic model to quantitatively assess the performanceof tree validation is now provided. Assume for example that the SML is afull tree of depth d. The validator has a complete reference treerepresenting a known, desired platform configuration. Recalculating hashoperations may be the dominant cost factor to estimate validationcomplexity, while comparisons may be cheap. Assume a random set offailed leaves.

An optimistic validation strategy may be used, called diagnosticvalidation, which traverses the paths from the root to failedcomponents, i.e., components with bad measurement values with respect tothe leaves of the reference tree. One property of this strategy is thatit finds failed components with authentic measurement values. Diagnosticvalidation may proceed as follows. When visiting an inner parent nodewhich differs from the corresponding node in the reference tree, i.e., abad parent node, one of the situations in FIG. 9, case (b), or therightmost configuration of case (c) may be encountered. In the lattercase, no recalculation of the parent node may be performed since it isan obvious SML integrity failure. The subtree with this rootconfiguration may be discarded from further traversal, since it may notyield trustworthy information about failed components. In this case,further steps may depend on the validator's policy. The nodeconfigurations in case (b) are the ones that may require re-calculationof the parent hash from the root hash by one extend operation 0, toconfirm that the configuration, which may be unknown from thevalidator's reference tree, is authentic. The subtrees whose roots aregood children of the bad parent node under scrutiny, may be discardedfrom further traversal. This procedure of diagnostic validationimplicitly excludes the configuration/case (a) and the three leftconfigurations of FIG. 9 from diagnostic validation. They may beconsidered in further forensic evaluation of the SML tree, wherever thismakes sense.

Diagnostic validation may require a visit and performing a hashoperation at bad inner nodes in the union of paths from failed (bad)leaves to the root. In an otherwise untampered tree, this may implicitlyexclude the right configuration/case (c) with bad parent node. A subsetof independent and ideally distributed (i.i.d.) bad leafs constitute afraction fε[0,1] of leafs. The number of bad leafs is 2^(d) f. Theexpected number E^(inner) (f) of bad inner nodes may be calculated asexplained below.

One problem addressed herein may be that of bi-coloring (e.g. bad vs.good inner nodes) of a binary tree generated by a random, i.i.d. choiceof leaves and coloring of the path connecting it to the root. Randomchoices of such leaves and paths may be equivalent to random choices ofi.i.d. bit strings of length d. The expected number E_(k) ^(N) ofcolored leaves after k choices from the set of N=2^(d) leaves iscalculated. Recursively,

${E_{0}^{N} = 0},{{{and}\mspace{14mu} E_{k + 1}^{N}} = {{{E_{k}^{N}\frac{E_{k}^{N}}{N}} + {\left( {E_{k}^{N} + I} \right)\frac{1 - E_{k}^{N}}{N}}} = {I + E_{k}^{N} - {\frac{E_{k}^{N}}{N}.}}}}$

Solving this obtains: E_(k) ^(N)=N(1−(1−N⁻¹)^(k).

Since all substrings of the chosen bit-strings are statisticallyindependent the same argument applies to inner nodes at levels d−1, . .. 0. Thus, the expected number of colored inner nodes is obtained bysummation d−1

$E_{k}^{inner} = {\sum\limits_{l = 0}^{d - 1}\; {E_{k}^{2^{1}}.}}$

Remaining to be found is the expected number of choices k whichcorresponds to a certain expected number E_(k) ^(N)=fN of coloredleaves, where 0≦f≦1 is a target fraction of leaves. Solving thisequation for k yields

${k = \frac{1\; {n\left( {1 - f} \right)}}{1\; {n\left( {1 - 2^{- d}} \right)}}},$

where N=2^(d) was inserted. From this, the expected number of bad innernodes in dependency of f, E_(inner) (f) may be calculated.

FIG. 10 shows the fraction of the 2^(d)−1 inner nodes, for d=16, atwhich a hash operation may occur under the above descriptions. Thisrepresents the number of hash operations which may be needed todetermine the bad components with certainty. The reference case of alinear SML may require 2^(d)+1 hash operations to recalculate the finalPCR value. This case is roughly represented by the upper ordinate axisof FIG. 10.

With regard to comparisons to reference values, the situation may beslightly different. Tree traversal for diagnostic validation may descendalong the bad inner nodes which fail comparison with the referencetree's corresponding inner node. For that, both children of a bad innernode may be compared in each case, so that the complexity in terms ofcomparisons may be twice the number E^(inner) (f). The linear SML mayrequire all 2^(d) measurements to be compared with reference values.

If h is the cost of a hash operation at the validator, and c the cost ofa comparison of two hash values (160 Bit for SHA-1), then the totalvalidation cost of the linear case is(2^(d)+1)h+2^(d)c=2^(d)(h+c)+h>2^(d)(h+c). This is the least effort toobtain the same information from a linear SML as by diagnosticvalidation of a tree-formed SML. For the tree-formed SML on the otherhand (including the root in the count), the cost is (E^(inner)(f)+1)(2c+h). Tree-formed validation is more efficient if

${{\frac{{E^{inner}(f)} + 1}{2^{d}} \leq \frac{h + c}{h + {2c}}} = \frac{\lambda + 1}{{2\lambda} + 1}},$

where λ=c/h<<1. And even with a very generous margin, λ<0.01, whichyields a bound of 0.99 for the r.h.s (right-hand side). Then for d=16,tree-formed validation may be more efficient for fractions f of badleaves as high as 85%.

Diagnostic validation of a tree-formed SML may perform better in termsof hash operations than with a linear SML, and may outmatch the linearSML even for large fractions of bad components. Diagnostic validation ofa tree-formed SML may be vastly advantageous for small fractions offailed components. Tree validation may be more efficient when the badleaves are non-uniformly distributed, e.g., exhibit clustering.

While both directly compared linear and diagnostic tree validation areavailable, linear validation may be impossible if the recalculation ofthe final PCR fails, since then, comparison of single measurements doesnot yield reliable information—each measurement may be faked in the SMLto hide the one which broke the hash chain. One advantage of tree-formedis that validation data may come about even at decreased computationalcomplexity for the validator.

With regard to the tree-formation algorithm itself, to achieve the samelevel of security as TCG standard compliant trusted boot processes,operations on verification data registers may run inside thehardware-protected TPM environment. Although part of the operations inmost operations of the tree formation algorithm listed above are nonstandard TPM functions that may be executed on standard conforming PCRs;in fact, the normal extend operation E₁ may be an internal standardfunction, and S_(v) and S_(m) may be realized by PCR read operations.

The minimal modifications that may be needed to extend a TPM to turnPCRs into tree-formed verification data registers are discussed, whilethe tree-formation algorithm may run outside the TPM. Then, aTPM-internal command for tree formation is described. Anotherimplementation is described which is a software-based implementation oftree-formed verification data, where the root registers may be softregisters managed by a trusted application, and where the current stateof such registers is protected by a ‘real’ register, e.g., a PCR.Finally, the experimental implementation of tree-formation with the TPMemulator integrated in the TPM software emulation Environment, “ethemba”is described.

A minimalist approach is taken to implement tree formation and carve outchanges to a standard TPM that may enable PCRs for use with theAlgorithms 1 and 2. This approach regards implementing the elementaryoperations listed above by TPM commands or modifications thereof. Thecore of the algorithm, including the bookkeeping tasks on registersrepresenting inner nodes' current states, may be realized as a softwareroot of trust for performing tree formation in a system integritymeasurement process, such as authenticated or secure boot.

The operations S_(v) and S_(m) pose no problem and may be realized byTPM_PCRRead commands or directly in the tree formation software,respectively. Ei may occur at every right edge at the lowest level ofthe tree, and may extend a V containing an already measured value whichcame from the left sibling of the measurement which is extended into V.Therefore, E₁ may be included in the standard TPM_Extend operationdefined by Equation (1). E₂ may occur at right edges inside the treeand, in turn, may be modeled by TPM_PCRRead followed by a TPM_Extend.

Operations M and V may occur at left edges on the lowest levelrespectively, inside the tree. They may pose a problem for two reasons.First, PCRs may not be directly written to, and a natural approach toreset them via TPM_PCR_Reset as a first step in M or V may beproblematic, since only PCRs above 16 of a standard TPM may be reset,and only from the correct locality. Thus it is necessary that enoughPCRs are resettable and that they respond to the locality in which thetree formation software is executed as a trusted code.

Second, even after reset, the operation that may modify a PCR,TPM_Extend, may not directly copy a value into the register but trulyexecutes (1) with the existing value of the reset PCR, which is a 160bit binary 0x00 and the input value, which yields a result differentfrom the input value. One option, which avoids exposing new commandsdirectly writing to, or shifting values between PCRs, may be to augmentPCRs with a reset flag which indicates that they are in a pristine stateafter reset. Then, TPM_Extend may be modified such that it directlywrites into the PCR when this flag is true, and then sets it to false.

Realizing that M and V consistently occur at left edges of a tree, andif the right sibling is empty (nil), and then deterministically producean outcome depending on the two siblings involved, a third option wouldbe to deviate slightly from the definition of a Merkle hash tree. Thecorrect configuration of values in each elementary triangle in the SMLtree may then be as shown in FIG. 11.

That is V or M may be modeled by TPM_PCR_Reset followed by TPM_Extend toobtain 0⋄x=H(0∥x) in the first step. The right sibling may then benormally extended in that register and the result written to the SML. Aconsistent treatment of nil node values in intermediate stages andfinalization of a tree is also described below.

In many cases, the hash tree stored in the SML may be incomplete, i.e.,contain empty leaves and inner nodes. In the continuous measurementprocess, such nodes, with value denoted nil, may be treated procedurallyby the operations M and V which means that right nil siblings may beignored. This happens in lines 8 and 18 of Algorithm 1 for intermediatestages of tree formation, and in line 29 of Algorithm 2 at completion ofthe tree after the last measurement.

Generally, i.e., transgressing the restrictions of a standard TPM, nilmay be two-sided unit for the operation ⋄, i.e.,

x⋄nil=nil⋄x=x, and nil⋄nil=nil  (Equation 3)

This convention manifests rule/case (d) as described above. It is areinterpretation of the usual extend operation and may also be used toeliminate the operations M and V in the algorithms' formulations.Namely, M and V may be replaced by a reset of a register V to nilfollowed by the operation V←V⋄m, respectively V←V⋄V.

For the implementation of this convention, nil may be represented as anadditional flag of PCR registers, and the inputs and output of ⋄. For aPCR, the nil flag may be set by a particular reset command. When nil isencountered as the input of an extend operation to a PCR, then logic ofthe TSS, or a TPM modification, may prevent execution of the hashoperation (1) and write to the PCR directly.

The split TPM/software implementation of tree formation compromises onthe security level of the resulting root verification data registervalues. Tree-formed verification data may be produced by a TPM-internalimplementation of the proposed algorithms. For this, a TPM modificationmay work as follows. The modified TPM may expose a commandTPM_Tree_Extend with the same input parameters as the usual TPM_Extendcommand. The TPM may maintain flags for PCRs signifying which of themare currently designated tree roots, which are occupied and locked, andwhich are usable as intermediate Vs by the Algorithm. Furthermore, theTPM maintains the additional data mentioned above. In the simplest case,internal logic may prevent concurrent use of more than one PCR for treeformation. While TPM_Extend may output the update of the target PCRvalue, TPM_Tree Extend may return a variable number 1, . . . d ofupdated verification register data values in sequence such that theyproduce the natural order described above. These return values may bethe output of the SML write operations of Algorithms 1 and 2. When dvalues are returned, the receiver may know that this tree is exhaustedand the corresponding root V locked. Another option may include theTPM_Tree_Extend to return all intermediate V s on each call.

A method is described for using Merkle hash trees to protect theintegrity of the secure start up process of a trusted platform in thesame way as is traditionally done with PCRs. Efficiency and flexibilitygains have been demonstrated resulting from using tree-formedverification data in platform validation. This may be effective inparticular in the remote validation and management of platforms via anetwork. Given the small size and complexity of the tree-formationalgorithm, it may be implement operations directly inside the TPM, ifspecifications are amended accordingly. This may be a feasible approachfor future TPM generations.

With regard to generalizations, trees are certainly not the most generalstructures for which integrity protection using cryptographic digestscan be applied. For example, some researchers have extended hashes toprovide identification of directed graphs. Others have applied variantone way functions, e.g., multi-set hashes to uniquely identify complexdata structures such as RDF graphs. Along these lines, generalization oftree-formed verification data to, for instance, directed acyclic graphs,and dependence graphs, may be conceived. While potentially interestingfor complex platform management and protection tasks, every suchgeneralization would incur increased complexity and loose the efficiencyof binary trees for validation. Application cases for suchgeneralizations are therefore not undertaken at this stage.

The single command extension of the TPM integrity measurementfunctionality, TPM_Tree_Extend proposed above may be, however, thestarting point of a flexible, TPM-based tree verification datamanagement architecture. Secure updates of subtree roots may be enabled,such as for dynamic platform management for example, and ultimately toquote an inner node of a tree-formed SML with the same securityassertions as TPM_Quote provides to a remote validator for a PCR value.Such further extensions are described below.

Structuring the measurements helps in identification of the componentthat failed integrity check. In one such embodiment of structuring,measurements may be organized in a linear chain and the verificationdata be derived as: V_(i)=f (V_(i-1), m_(i)), _(i=0, 1, . . . n-1),where n is the length of the linear chain, mi denotes the i-thmeasurement, and Vi denotes the verification data derived from the i-thiteration in the linear chain. The final value V_(n-1), derived byprocessing the n measurement hash values of components, may be used asthe verification data. There may exist a trusted reference value R_(i)for every V_(i): i=0,1, . . . , n−1. If during a verification process,the final value V_(n-1) is indicated as differing from its referencevalue R_(n-1), then this indicates a mismatch of at least one of theinterim value V_(k) to its reference value R_(k). Such a mismatch may bedue to failure of the integrity of some component, or simply due tomismatch in comparison between a correctly computed (and/orintegrity-intact) verification data Vj against a corrupted or erroneousreference data Rj. With the measurement log as a chain (V₀ to V_(n-1)),the first occurrence of the mismatch of the verification data to itsreference value may be found by using Algorithm 1 as shown in FIG. 12.There are n elements and the indices range from 0 to n−1, and integerdivision is performed for index manipulations.

The reference values {Ri: i=0,1, . . . , n−1} may be trusted andun-compromisable. In this case, any mismatch indicates either a failureof the integrity of the i-th component, or, the i-th component itselfmay be integrity-intact but its measurement m, may itself becompromised. In either case, in operational verification systems it maybe declared that the i-th component is untrusted and may be remediatedbefore loading. Algorithm 1 finds the first occurrence of the failure;but it may not find the-subsequent failures.

To optimize the search of the failed integrity check module, theverification data may be generated in the form of a hash tree of storedmeasurement logs (SMLs) as described in the tree-formed verificationprocedure as described above. The stored measurement log is organizedinto a balanced binary tree and algorithms are presented to generate thetree using TPM commands. The algorithm is generic and may be extended tobalanced n-ary trees where n>2.

The concept of tree-formed verification as described above is extendedto consider tree-formed verification where the tree is unbalanced.Further they may be extended to consider the interdependencies betweenthe software components. The term device is used to indicate any entitywhose integrity of software/firmware/hardware is being verified. Notethat the entity may be a home gateway, M2M gateway, access point,H(e)NB, HNB, a Relay Node, a mobile device, a tablet device, or anyother gateway or device.

Without loss of generality, certain software components may be subjectto more attacks when compared to other components. For example, in adevice, the communication protocol stack may be hacked more often than acomponent enabling cosmetic features. This argument is also applicableto functionalities. In remote validation and semi-autonomous validation,the integrity measurements are sent to the platform validating entity inthe network. Such a validating entity may observe and retain history ofthe failed components or functionalities.

Also, it may be generally assumed that when devices (and/or theirsoftware components and/or functionalities) come under attack and/or getcompromised of their integrity, the impact or cost to the devices'stakeholders may vary depending on the components/functionalities.

The above aspects render necessary a component/functionalityverification strategy where the frequency and/or severity of cost orimpact of the attacks may be considered and reflected in the design ofthe verification data structures and verification algorithms.

First, however, consider the case of different frequencies (orprobabilities of occurrences) of attacks. Based on the integrity failurefrequency of software components or functionality, a probabilitydistribution function (PDF) of integrity failure over the softwarecomponents or functionality may be estimated and used in theconstruction of the verification data structure. The probabilitydistribution is a discrete distribution function and may be representedas a vector (P₀ to P_(n-1)), for a device with ncomponents/functionalities. Such a probability distribution function maybe generated by averaging all the observations or a windowed averagewhere the average is performed with the last, sufficiently abundantsamples. Additionally the averaging may be non-weighted mean or aweighted mean with a weight function W[n]. Examples of weight functionsare, but not limited to, exponential, Gaussian, etc. Overlapping ornon-overlapping sliding windows may also be used to obtain PDFs thatvary in the temporal domain. This probability distribution vector (orvectors) may be communicated to the device either by messaging orconfiguration. Without loss of generality, we assume a temporallystationary set of PDFs {P₀, . . . , P_(n-1)}.

At the device, using the distribution (PDF) and the hash integritymeasurement values of the software components, an optimal hash tree maybe constructed using Huffman's algorithm, arithmetic coding or similarsuch optimal coding tree constructing algorithm. FIG. 13 illustrates anexample of the tree construction using Huffman's code. The advantage ofconstructing such a tree is in the fact that the most frequentlyattacked components have a shorter code length and expected value of thesearch time is reduced. Thus the overhead in searching a failedcomponent or functionality is reduced. Also, components that areexpected to be under attacks the most frequently will be searched theearliest.

For the Huffman's algorithm or the arithmetic coding algorithm to work,the probability may be non-zero. Thus those components orfunctionalities whose probability of attack is zero may be dropped inconstructing the tree. This may result in a reduced size of the treereducing the communication overload and search time. Alternatively, ifall nodes are to be included then a very small non-zero value of δ maybe assigned to components or functionalities with zero probability ofattack. Generally, since the probability distribution of attacks will benon-uniform, the resulting tree will be non-balanced.

In the network, such a tree may be pre-constructed and populated withthe derived hash values by a certified authority based on themanufacturing time setup of the device or after an authenticated,authorized and integrity verifiable software/firmware update and storedsecurely for reference. In the device, each time the device bootssecurely, this tree may be reconstructed using the PDF of attackfrequency by applying the optimal code tree algorithm (such as Huffman'scode, arithmetic code) if it is not pre-constructed and stored and thenodes and the root are populated with the evaluated hash values (orextended PCR values).

An algorithm may be developed to populate the nodes of the tree and theroot of the tree at the device using the measurements of the softwarecomponents. Such a verification tree may be then sent by the device tothe platform verification/validation entity in the network and comparedwith the reference tree to establish the trust state of the device andto uniquely identify the failed nodes. The algorithm is describedherein.

To reduce the communication overload, a pruned tree of a specific depthd which includes the root and nodes at depth d, d−1, . . . , 0 may besent. The depth d may be evaluated based on threshold values. Anothermethod of pruning is to drop any node whose cumulative probability ofattack occurrence is less than a specified threshold. Yet another,possibly more reasonable method may be to prune the tree of allremaining nodes when the cumulative distribution values for nodes thathave been included in the tree have exceeded a specified threshold. FIG.14 illustrates the tree pruning for a depth d=2.

FIG. 15 illustrates the system diagram and the communicationinterchange. FIG. 15 illustrates, at 1, based on Attach history,generating a discrete probability distribution of attack overcomponents/functionalities. At 2, Huffman's coding algorithm is used togenerate a code tree. The probability distribution of attack iscommunicated to a device, at 3. Huffman's coding algorithm is used togenerate a coding tree at the WTRU, at 4. At 5, during secure boot, thetree is populated with trust values. The trust tree is communicated fromthe WTRU at 6. At 7, the tree is verified with reference and the tree issearched for failed nodes. Corrective action is taken at 8.

In the above description, the use of non-balanced trees resulting wasseen by considering a non-uniform attack probability model forcomponents. In addition to the attack probability, the cost or impact ofany attack may also be considered. Suppose that any i-th component (i=0,1, . . . , n−1) of a device is associated with {Pi, Ci}, where P_(i)denotes the probability of occurrence and C_(i) denotes the cost orimpact to the stakeholder. Then, the components may be ordered by“expected cost (impact) due to attack/compromise” where the ordering isdone by comparing: E(cos t)_(i)=P_(i)×C_(i). Then the normalized,fractional expected cost may be determined by:

${{Ef}\left( {\cos \; t} \right)}_{i}{\frac{{E\left( {\cos \; t} \right)}_{i}}{\sum_{k = 0}^{n - 1}{E\left( {\cos \; t} \right)}_{k}}.}$

Once the components are ordered (from highest to lowest normalizedexpected costs), then one may use the same Huffman coding or Arithmeticcoding to form the trees. A verification tree formed this way may givethe most weight (for search) to the components whose failures may havethe highest expected cost/impact to the stakeholder.

A tree structure by itself may not completely capture theinter-dependencies of the software structure. For example, there may beshared libraries that may be used by different components. Therefore toindicate such interdependencies, links are added in between the nodesand the nodes/leaves of the tree after the initial optimal code tree isconstructed. Thus, the tree is extended to capture the softwarearchitecture of the device or the interdependencies of the components.The tree leaves may be mapped to the software components and nodes tothe libraries and archives. Interdependencies of the software modulesand shared libraries may be mapped by surrogate child links. The treethus becomes a generalized tree. The algorithm to populate the nodeswith the measurement values may be modified to traverse the surrogatechild links additionally. FIG. 16 illustrates a tree with such surrogatechild links where the software component or functionality indicated bymodule A depends on or utilizes the shared library represented by moduleD and similarly the software component or functionality indicated bymodule B utilizes the leaf component/functionality C.

If the devices include a trusted execution environment, such as a TrEfor example, to ensure the trusted operation of the algorithm and/or thetrusted population of the nodes and/or the root with derived hashvalues, the algorithm may use the trusted operations and instructionsprovided by the TrE.

If one uses a Trusted Platform Module (TPM) and an upper-layer TrustedSoftware Stack (TSS) to construct such a TrE, appropriate commandextensions for the TPM as well as the TSS may be considered.

As described above, any optimal code construction algorithm may be usedto construct the tree. An example was presented where Huffman'salgorithm was used to construct the tree.

In the following description, the leaves represent the softwarecomponents or the functionalities. For simplicity, the components arereferred, but the arguments may be applied to functionalities as well. Acollision resistant hash function H may be used to compute themeasurements of the components. Let the function F be used for computingthe metric of the nodes by using the metrics of the children of the nodeunder consideration. The algorithm Populate_metric may be called withNode set to Root of the optimal code tree. The metrics of the leaves ofthe tree are initialized to the measurement of the correspondingcomponents.

Algorithm 2 shown in FIG. 17 performs the post-ordering traversal of thetree and computes the metrics of the internal nodes and populates thenodes with the computed metric values. To adapt the algorithm for a TPM,the function F is the PCR Extend operation. In the following algorithm,the Reg_Number is a subscript index indicating the PCR register number.

Algorithm 3 as shown in FIG. 18 is a modification of Algorithm 2 (FIG.17) to work with the PCR registers and use the PCR_Extend operation.Algorithms 2 and 3, as shown in FIGS. 17 and 18 respectively, may bemodified to work with n-ary trees. However, Huffman's algorithm may bemodified accordingly to generate the trees. Instead of adding lowest 2probabilities to add for left and right child, n lowest probabilitiesare added. Accordingly the labeling of the branches contains log 2(n)bits. For example, for 4-ary trees, 4 probabilities are added and labelthe 4 branches as 00,01,10,11. Algorithm 4, as shown in FIG. 19, is anupdate of Algorithm 2 for n-ary trees. And Algorithm 5, as shown in FIG.20, may be updated similarly.

To construct a tree that is generalized to handle the surrogate childlinks as described above, Algorithm 3, as shown in FIG. 18, may beupdated. Algorithm 5 is an update of the algorithm 2 in consideration ofsurrogate child links. Initially a binary tree is constructed using theHuffman's algorithm. The interdependencies are added later as surrogatechild links. The labels 0 and 1 that are attached to the left and theright child are still used for finding the code of any leaf. Thesurrogate child links may be used to populate the metric in the nodes.No label may be attached to the surrogate child link itself.

After the nodes are populated with the metrics, the verification treemay be sent to the validating entity in the network. The comparison ofthe integrity tree with the reference tree is performed. This may beperformed according to algorithm 6 as shown in FIG. 21.

Algorithm 6, as shown in FIG. 21, may be effective for (generallyun-balanced) trees that do not have surrogate child links due topresence of inter-nodal dependencies.

The same algorithm may also apply if a tree with surrogate child linksis processed as well. In this case, the algorithm is run without doinganything special to the surrogate child link relationships. When runthis way, the algorithm still obtains the same pruned tree of failedcomponents. The surrogate child links, however, provide additionalvisibility into the failure, because, when a component is identified ashaving failed integrity check, according to the algorithm, the surrogatechild link relationship gives insights on which other node (that may notsit directly above the failed component) may also be impacted by theidentified failed components.

In another variant of the algorithms described above, one may implementthese and similar fault-detection algorithms in an ‘interactive’ way. Inone embodiment, referring to back FIG. 14, for example, the sender maysend measurements for nodes residing only up to a certain internal-depthd≦D, where D is the depth of the longest branch. The verifier may verifythose internal nodes.

If a failure is detected, then the verifier may request for more data,corresponding to the sub-tree below the failed internal node, to be sentfrom the sender. The sender obliges, and the verifier may then examinethe integrity of the deeper-level of measurements. The method maycontain more such interactions, instead of just two interactions.

An “interactive” protocol such as described above may make sense to useif it is difficult to send all tree-formed SMLs for all nodes of a treeat once, due, for example, to communication bandwidth or payloadlimitation reasons. A fully-formed binary tree contains at most doublethe data of a linear chain structure of SMLs. The extra amount of datathat needs to be sent depends on the depth and fullness of the treeformation, but in some cases, the extra amount of data that even afully-formed binary tree needs to send may be modest, for example, somemore Kilobytes of measurement values. However, an interactive protocolmay be more reasonable to consider if trees are annotated with moreexpressive, semantic validation data such as detailed certificates, RIMcertificates or OMA DM information or similar and thus are large interms of data size.

The binary tree-formed validation data structure may result from aparticular, specific choice of validation system optimization criterion,which are 1) assured means to verify compromises to internal SMLs, and2) fast search of compromised components. A binary tree-formedvalidation data structure, however, incurs costs such as 1) increasedcomputational cost of fully constructing the tree at both the device andthe verifier, and 2) increased cost of storage due to the need tostoring internal SMLs (up to the twice the amount of linear SMLs). Atree may not be the best structure if there is a lot ofinter-dependencies in various components of the device.

Other types of system optimization criteria may result in a validationstructure that may be different from trees. For example, linear SMLstructure may be the best option if one is interested in absolutelyminimizing the internal storage medium but at the cost of losing thefast and fine-granular ability to detect failures.

Another possible optimization criterion may be ease/speed of quicklydetermining the integrity of a vicinity (such as a small rectangle or aring around) of one or a small number of known at-risk component(s)where the neighboring components are known to have high, unstructuredinterdependencies. In such cases, non-tree-formed validation datastructures that may look like interconnected rings or meshes may arise,for example. For more general treatment of this topic, a graph-theoreticinvestigation may be applied.

Secure operations with tree-formed, protected verification dataregisters are described below. Functionality is conceptually added toTrusted Platform Modules (TPMs) to handle Platform ConfigurationRegisters (PCRs) which represent roots of hash trees protecting theintegrity of tree-formed Stored Measurement Logs (SMLs). This enablesverification and update of an inner-node of an SML and even attestationto its value with the same security level as for ordinary PCRs. As animportant application, it is shown how certification of SML subtreesenables attestation of platform properties.

More trusted functionalities may be added to operate on tree-formedverification data. It is shown inner nodes of a tree-formed SML with itsroot protected in a verification data register, may be verified forintegrity, and updated with a new value, in a controlled way maintainingthe overall security level. A variant of the TPM_Quote command for innertree nodes is introduced, which may attest to their integrity preciselyas TPM_Quote does for an ordinary PCR's value. With the defined set ofcommands, the integrity measurement functionality of a TPM may becomplemented by a comprehensive set of commands operating withtree-formed PCRs and SMLs. Using them, tree-formed verification and/orvalidation data may be used with far more flexibility and expressivenessthan ordinary, linearly chained TPM PCRs and SMLs.

A basic system model and notation is also described. Also provided isthe TPM command extensions described above and is defined, and alsoprovided are some pertinent structural extensions and basic usagecategories for such operations. As a central use case for the introducedcommands, also provided are exhibits for a protocol for certification ofthe root node of a subtree in a tree-formed SML by a trusted third partyand a brief assessment of the tree-formed platform validation approachand an outlook to future work is also described.

Minimal elements and capabilities of a platform, which may be requiredsubsequently, are described. TCG-nomenclature and some concepts are usedand described herein, but the embodiments described herein are notrestricted to platforms and secure hardware elements adhering to TCGstandards, such as TPMs, SMLs, and systems designed according to the PCClient specification for example.

The tree-formation variant of the extend operation defined aboveoperates inside a TPM, takes a single measurement value as input, and isotherwise inert with regard to the system outside the TPM. This is notthe case for the update function which is described herein. The latteroperates on a certain number r of verification data registers V, V def{V₁, . . . V_(r)} protected inside a TPM, and on the hash tree datastored outside the TPM in less protected storage.

That is, the hash tree contained in the Stored Measurement Log (SML) maybe managed by a Trusted Software Stack (TSS) which is authorized toaccess the TPM functions necessary for the update operations. TSS callsTPM via an authorized, integrity protected command interface. While TCGis used as common parlance for practical reasons, the concepts presentedhere are not restricted to a TCG, TPM and platform. A hardware-protectedset of verification data registers and an extend operation may be used.The latter may be defined by the ordinary TPM extend operation:

V←V⋄mdefH(V∥m)  (Equation 4),

where V denotes a verification data register, H is a collision resistanthash function (SHA-1 in case of the TPM), and m=H(data) is a measurementvalue. In the following ⋄ is used liberally with arbitrary registers Vas arguments, so that no confusion may arise.

The SML may contain a binary tree of depth d resulting from a binaryone-way operation, such as the Merkle hash tree for example, produced bythe TPM_Tree_Extend command described above. Natural coordinates forinner nodes and leaves are binary strings of length 1, . . . d, wherethe length l of the string is the level in the tree on which the noderesides. Let n be an inner node or leaf and write n˜

n

=(n₁, . . . , n_(l))ε{0, 1} x1 for the binary representation of thecoordinates of n. Let

n

=n_(k), k=1, . . . l, be the k-th digit of

n

. So that no confusion may arise, a node may be identified with itsvalue (e.g., 160-Bit hash value) in the SML, while distinguishing itfrom its coordinate. Otherwise, n=

n

) for the value-coordinate pair of a node.

The trace T of n is the ordered list of all inner nodes on the path fromn to the root, including n, i.e.,

T(n)=(t ₁ , . . . t _(l)), where t _(k)˜(n ₁ , . . . n _(k)).  (Equation5)

The natural partial order of nodes is written as m≦n, which isequivalent to nεT(m). The partial order extends to sets M, N of nodes bysetting M≦N if and only if ∀mεM:∃nεN:m≦n.

The reduced tree R of n is the list of all siblings of its trace. Thisis readily expressed in natural coordinates: R(n)=(r₁, . . . r_(l));where r_(k)˜(n₁, . . .

n_(k)), (Equation 5) where

denotes binary negation.

The hash chain operation x⋄y def H(x∥y), is used with fixed-length inputhash values x, y, in a variant which makes argument order depended on abinary parameter. For cε{0,1}, the following may be set:

x∥y

={x⋄y if c=1;

x∥y

={y⋄x if c=1;

This chiral Merkle-Damgard operation is a version of an extend operationwhich allows to distinguish between left and right siblings in a treeand calculate their parent node in the correct order. Neglectingimplementation issues, the (extended) TPM may be capable of performing

.|.|.

=internally.

In some cases, the hash tree stored in the SML may be incomplete, i.e.,contain empty leaves and inner nodes, denoted by nil. For the consistenttreatment of nil nodes in a Merkle hash tree, it is useful to assumethat nil is a two-sided unit for the operation ⋄, i.e.,

x⋄nil=nil⋄x=x, and nil⋄nil=nil  (Equation 6).

This is a re-interpretation of the usual TPM extend operation and canalso be used to model a direct write to a Vεv, by first resetting V tonil and then performing V⋄x for some value x. For the implementation ofthis convention, nil may be represented as a flag of verification dataregisters and the inputs and output of

.|.|.

. For a V, the nil flag may be set by a particular reset command. Whennil is encountered as the input of an extend operation to a V, thenlogic of the TSS, or a TPM modification, may prevent execution of theextend and write to the PCR directly.

The operational extensions of a standard TPM to operate securely withtree-formed SMLs are described. The protection goal is to achieve thesame assurance level for inner nodes and leaves of such an SML, as for aconventional verification data register value, protected in a PCR. Theupdate of a root by a new node value is first described, and thenfurther structural and command extensions are shown for use withtree-formed verification data.

The strategy for a secure update of an inner node or leaf of a SML treeis as follows. First, the current value of that node may be verified forauthenticity. This is done by recalculating the root of the tree,protected in a register V, (which is kept fixed in the remainder of thesection to simplify presentation) using the data contained in thereduced hash tree associated with the node. This verification must be aprotected operation inside the TPM, called TPM_Reduced_Tree_Verify_Load.It also loads the verified reduced tree data into a set of verificationdata registers for use with the subsequent update operationTPM_Reduced_Tree_Update. This function takes a new value for the node tobe updated, and uses the reduced tree data to update the parent nodes upto the root V. Both commands may be used separately for variouspurposes, for instance standalone node integrity verification. Forconvenience, they may also be combined into a single node and rootupdate command.

Suppose n is the node of an SML tree of depth d at level 1≦d with rootprotected in a verification data register Vεv. The first step is toupdate V with a new value for n, is to verify that the reduced tree R(n)is untampered in the SML.

To maintain the security level of V, this verification may be performedby a TPM-protected operation as well. For this, TSS callsTPM_Reduced_Tree_Verify Load with arguments ((

n

,n,R(n)). Choose l+1 available registers from V and call them B₁, . . .B_(l), and V*. Algorithm 1 as shown in FIG. 22 shows how an SML node isverified and its reduced tree is loaded into a set of verification dataregisters.

The chiral extend used centrally in this algorithm ensures correct orderof the child nodes in the calculation of their parent element on thetrace of n. The TSS obtains the calculated trace T(n) and theverification status as return values. In algorithm 1, as shown in FIG.22, l+1 there are additional verification data registers.

A simple variant of Algorithm 1 in FIG. 22 may operate using a singleverification data register, by processing the reduced tree sequentially,without storing the reduced tree inside the TPM. This auxiliary commandTPM_Reduced_Tree_Verify may be useful for a plain verification of theSML by the TSS or another party. This is shown in Algorithm 2 as shownin FIG. 23. The serialization of R(n) required by this variant may bedone using an input buffer realized in a software layer below the TSS,e.g., a TPM device driver, or by corresponding TPM internal logic.

Like the original tree formation algorithms as described (FIGS. 4 and 6)Algorithms 1 and 2 (FIGS. 22 and 23, respectively) use non-standardoperations, in particular chiral extend. Since the output target ofchiral extend is always a verification data register, the operation maybe implemented by loading the other argument into another verificationdata register (if it is not already there, as in Algorithm 1 in FIG.22), and preceding the TPM-internal operation 0 with a register swap,depending on the middle argument of chiral extend. This may ensure thesame protection level for all arguments.

The verification performed by algorithms 1 and 2 of FIGS. 22 and 23respectively has a limited meaning since it assures the integrity of theinput node value with respect to the input reduced tree. In case of anintegrity breach of the SML tree, more detailed information isdesirable. At least the tree level at which an integrity breach occursmay be obtained, by performing the validation strategy via the downwardtree-traversal described above.

The command TPM_Tree_Node_Verify shown in Algorithm 3 (FIG. 24a )returns the level at which an incorrect reduced tree and/or traceelement first broke the integrity chain from the root to n. It does notallow to determine which sibling broke the chain. Further diagnosticsmay be possible when a reference tree is available as described above.

TPM_Reduced_Tree_Verify_Load may be performed for a node n which may beupdated with a new value n′. The command TPM_Reduced Tree_Update, shownin Algorithm 4 (FIG. 24b ) is called with argument n′ and may operate onthe result of a determined, preceding TPM_Reduced_Tree_Verify_Load,which fixes the node coordinate (n) and the register V to be updated. Toachieve this binding in a command sequence, various methods can beemployed.

First, the TPM may store and manage states and additional data for treeoperations as described below. Furthermore, the sequence of commandsTPM_Reduced_Tree_Verify_Load and TPM_Reduced Tree_Update may be boundcryptographically, for example by rolling nonces as implemented by TPMprotected OIAP/OSAP authorized command sessions. Finally, the twocommands may be joined to a single update command TPM_Tree_NodeVerified_Update, with arguments (

n

, n, n′,R(n)). The node update commands return the new trace of n″ andthe new value of V, with which the TSS then updates the SML.

With the association of verification data registers to certain nodes orroots of hash trees, and the associated commands TPM_Tree Extend(defined above), TPM_Reduce d_Tree_Verify_Load, TPM_Reduced_Tree_Update,these registers V acquire statefulness. States of particular importancemay be:

Active Root (AR) signifying a root of an SML tree currently underconstruction by the TPM_Tree_Extend operation.

Complete Root (CR) signifying the root of a tree which is the completedresult of the measurement of a number of components, i.e.,TPM_Tree_Extend operations. AR may transition to CR when the tree isfull, i.e., contains 2d leaf measurements, or triggered by the TSS if itis desired to close a tree at a certain stage. A V in CR state may beprotected against further updates with TPM_Tree_Extend, but may beaccessed by TPM_Reduced_Tree_Update or even the normal TPM_Extendoperation depending on policies and authorization.

Tree Build (TB) signifying a register used to build an active tree inanother, AR register by the TPM_Tree_Extend operation.

Reduced_Tree_Node (RT) signifying the result ofTPM_Reduced_Tree_Verify_Load, i.e., one of the registers B_(k). An RT Vmay be protected until the corresponding TPM_Reduced_Tree_Update, oranother, authorized command occurs.

When more than one tree is managed, Vs' states need to be associated totheir respective trees, e.g., using Unique Identifiers (UIDs).Furthermore node coordinates may need to be stored for each or someregister(s). These data may be held in a Verification Data AllocationTable (VDAT) inside the TPM, and managed by a Tree Data Management Unit(TDMU).

TPM protected verification of a node value may enable a new coresemantic for platform validation by attestation. In particular, avariant of TPM_Quote may be defined that attests to a certain nodevalue. Such a command TPM_Tree_Node_Quote may be called with the samearguments as TPM_Quote plus the arguments of TPM_Reduced_Tree_Verify. Itthen executes Algorithm 2, as shown in FIG. 23, but additionally keeps acopy of n in another PCR V′. Upon success it executes TPM_Quote on V′.The receiver of such a quote should be made aware that the signatureobtained is over an SML tree's inner node. One possibility would be tochange the fixed string contained in the signed blob of the TPM_Quotecommand, which normally is “QUOT” to say, “TREEQUOT”.

Attestation to a node value with this command provides to the node thesame security assertion as quoting a verification data register (PCR)value with TPM_Quote. However, it may bear the additional semantics thatthe value corresponds to some inner node of an SML tree, i.e., iteffectively attests to the state of a certain subtree of which n is theroot. To explicitly convey this semantics to a validator, additionaldata may be included in the AIK (Attestation Identity Key) signedattestation package, e.g., a string “Tree Node”. The meaning of such anattribute can be sensibly strengthened, if it is assigned byTPM_Tree_Node_Quote if the root register is a controlled SML rootregister resulting from TPM_Tree_Extend commands, i.e., it is in the CRstate, as discussed above. This control may be part of the quotegeneration.

For the validation of an attestation message, the validator may need thevalue n of the quoted node n=(n,

n

). More information transfer to the validator may not be needed,therefore the above description of TPM_Tree_Node_Quote follows aprinciple of minimal revelation. A variant of the command may also signthe node coordinate (n), if the position of the node in the SML treematters for validation. Extended validation data transferred to avalidator may include the reduced tree of n and root verification dataregister.

As an alternative embodiment, it may be possible to task the validatorwith the verification of the reduced tree. This approach is usedelsewhere to attest to the integrity of Web pages delivered by a Webserver, and to bind this to an attestation of the server's state usingthe ordinary TPM_Quote command. This brings forth a variant realizationof TPM_Tree_Node_Quote, as follows.

The command receives as arguments the node value n, the node values ofR(n), and a selector for the root V. The TPM signs this (concatenated)data after controlling the CR state of V and with a “REDTREEQUOT” fixedstring attribute. It is notable that for the approach used to attest theintegrity of Web pages, a workaround method is used to bind a reducedtree to a quote from a TPM, by inserting a hash of these additional datainto the nonce input of the TPM_Quote command, which is normally used toguarantee freshness of the quote.

The first and second realization variant for quoting an inner noderepresent opposite possibilities, in the sense that the first putsverification load with the platform, while the second puts it with thevalidator. Therefore, both may have different domains of practicalefficiency. For instance, many, distributed validating platforms as inM2M communication for the first, and many, distributed validators (suchas the Web clients as described above) for the second variant. But thesecond variant has, by principle drawbacks with regard to informationrevelation of the platform, since the validator is shown the completestate represented by V. This may be detrimental to privacy.

The various extensions of the TPM integrity measurement functionalitiesintroduced here may be grouped into the following categories.TPM_Tree_Extend is used in the continuous measurement process thatbuilds a particular SML tree with PCR protected root.TPM_Reduced_Tree_Verify_Load, TPM_Reduced_Tree_Verify, and ultimatelyTPM_Tree Node_Verify are commands for platform-internal diagnostics.Apart from the usage of TPM_Reduced_Tree_Verify_Load as a preparationstep to TPM_Reduced_Tree_Update, they may be used to verify certainproperties of a platform, represented by SML subtrees, before otherevents may happen.

TPM_Reduced_Tree_Update and TPM_Tree_Node_Verified_Update may be usedfor the controlled update of subtrees. Particular usages of an innernode update operation are described as follows:

Update of a single system component. In this case the new value updatesa leaf

Update of a system module represented by a subtree. In this case theroot of the new subtree updates an inner node of the original tree.

Finally, TPM_Tree_Node_Quote is the command which makes tree-formed SMLusable for validation of a platform by a remote party. It exhibits thekey new element of validation using tree-formed data, namely thepossibility to attest to subtrees representing only a defined part ofthe system state. A particular use case is described below.

Command extensions may be used in tree-formed validation separately.Described below is a method which combines command extensions tovalidate subtrees in a modular fashion.

Validation using tree-formed SMLs and verification data registers addssemantics to remote attestation. The possibility to attest to subtreesof an SML enables expressiveness far beyond conventional remoteattestation. Tree-formed verification data is one way to substantiateother proposals to add semantics to platform attestation, e.g.,association and of properties to validation data, as in PBA. One problemof Trusted Computing is the association of semantics to platformattestation. TCG specifications define a bilateral remote attestation inwhich executed code is measured when it gets loaded. The measurementsare stored in PCRs as verification data, and the TPM attests to thesedata by signing them with a TPM protected Attestation Identity Key(AIK). Since a digest of a complete configuration is transmitted, theverifier may know configurations of the machines (at all times, ifsystem dynamics are considered). The transmitted data for validationthus lacks expressiveness to enable versatile and efficient remoteplatform validation. The need for semantic attestation was recognizedearly on, where it was proposed to restrict the scope of a singleattestation to a virtualized subsystem with limited complexity, allowingfor attestation of complex, dynamic, and high-level program properties.

Property and property-based attestation (PBA) are described herein. PBAallows assuring the verifier of security properties of the verifiedplatform via a trusted third party (TTP), called Subtree certificateauthority (SCA). The SCA issues a certificate which maps the platformsconfiguration to the properties (in particular desired/undesiredfunctionality) which may be fulfilled in this configuration. PBA movesthe infrastructural problem of platform validation to an SCA, similarlyto, but extending the role of, the TCG's privacy CA. Certification ofsubtrees is one way to overcome the problems described. One relatedembodiment is that of hardware-supported updates, performed by a TPMcommand which re-seals data for another platform configuration based onan update certificate.

In distinction to verification data, validation data is all data that issubmitted to another party, the validator, and used to assess thetrustworthiness of a state of the platform. The process of submission ofvalidation data to the validator, realized as remote attestationaccording to TCG for example, and evaluation thereof by the validator,is properly called validation. Validation data may comprise verificationdata such as quoted verification data register (e.g., PCR) values.Validation may, beyond cryptographic verification of verification data,include policy evaluation and triggering of actions by the validator.

Tree-formed verification data and validation data associated to an SMLtree, provide structured data which may be used in addition to theapproaches as described above to enhance the semantics of platformattestation. Another method for using tree-formed verification data isprovided to realize concepts related to PBA.

It is shown how an SCA may replace a node in an SML tree with ameaningful, trusted statement—a subtree certificate—about the subtree ofmeasured components of which the latter node is the root. This processrealizes a partial validation of the platform by the SCA and results ina trusted assertion that is ingested in the available validation data ofthe plat-form. This may later be used toward another validator tovalidate the platform more fully. Next, a generic base protocol forsubtree certification which may be implemented for variant realizationsand use cases is described. Variants are also described.

Subtree certification is a process by which a Trusted Platform (whichmay be, but is not limited to the combination of TPM and TSS in asimplified system model) obtains a certificate for the value of an innernode of a tree-formed SML from an SCA. For this, the platform submits asigned statement to the SCA, signifying that the node value is containedin an SML tree with root value protected in a verification dataregister. TPM is one possible implementation and any verification dataregister may be used. Based on this evidence, the SCA may issue acertificate with additional attributes about this node value to theplatform, which is then ingested into the SML tree. The process usesprotected tree operations.

The platform may possess an active AIK a, with certificate Ca issued bya trusted Privacy CA (PCA). Communication between the platform and theSCA is encrypted and integrity protected to mitigate man-in-the-middleattacks. An inner node s is selected for certification. In the protocol,failure conditions and negative responses are not mentioned. The subtreecertification protocol proceeds in at least five phases, as depicted inthe FIG. 26.

Phase 1 creates a quote over s. For this, TSS calls TPM_Tree_Node_Quotewith arguments (

s

),s,R(s),a) (for brevity, FIG. 26 does not show all arguments that maybe called) and receives back P=Sig_(a) (s).

If the root of the tree, i.e. the register V is selected forcertification, then TPM_Quote is to be used on V instead. In phase 2,the TSS creates an attestation package Q. It contains information forthe verifying SCA, at least: Q⊂{P,s, C_(a),a_(pub)}. The public parta_(pub) of a may be contained in Q when it is not evident from C_(a).Also, the value of s may be known to SCA and then be omitted from Q.

More information may be included, for example the node coordinate

s

, when it is part of the quote. Q is sent (encrypted with a publicencryption key of SCA and integrity-protected) to SCA. This phase issimilar as in remote attestation specified by the TCG.

Phase 3 comprises the activities of SCA. First, SCA may verify Q byverifying the signature of P and/or tracing the certificate chain, up tothe root certificate of the PCA. If the SCA recognizes s as a node valuewhich it may certify, it creates a manifest Ms for it. This manifest maycontain additional information about the platform state associated withthe presence of the subtree with root s in the SML, such as a timestamp, a functionality of the platform, the identification of a modulecombined from the loaded components represented by the leaf measurementsof the subtree, and/or another platform property. The manifest is thevalidation data added by subtree certification which provides semanticmeaning to the node value s to a validator. The SCA may create acertificate for s. This certificate, Cs, binds the propertiesrepresented by M to the platform, by binding it to the AIK a. This maybe done in two ways, namely:

$C_{s} = \left\{ \begin{matrix}{{{Sig}_{SCA}\left( M_{s}||P \right)}\mspace{59mu}} & {{{{if}\mspace{14mu} s\mspace{14mu} {is}\mspace{14mu} {revealed}};}\mspace{14mu}} \\{{Sig}_{SCA}\left( M_{s}||{{bind}(\alpha)} \right)} & {{if}\mspace{14mu} s\mspace{14mu} {is}\mspace{14mu} {{concealed}.}}\end{matrix} \right.$

In the first case, SCA signs the manifest and the AIK-signed node value,thus establishing an indirect binding to a. The binding of Cs to a, maythen be verified if the platform reveals the node value s. In the secondoption, the binding is achieved directly, by letting the SCA sign somedata bind(a) which uniquely identifies a, such as a's public part,C_(a), the serial number, or the fingerprint of C_(a). In the semanticsof Public Key Infrastructures, C_(s) is, by the binding, an attributecertificate associated with C_(a). Finally, SCA creates a package Rcontaining at least M_(s) and C_(s), and bind(a) in the second case, andreturns it to the platform.

Phase 4 prepares the update of the SML with certain data derived from R.The SML update may produce a binding association between the subtreecertificate and the certified node's position

s

in the tree.

This may allow the platform to assert to a validator that the propertyattested by C_(s) and M_(s) is present in the platform's configuration.Various ways of SML update to bind C_(s) to the represented subtree areconceivable, each suited differently for particular use cases.

A set U={u₁, . . . , u_(k)} of new node nodes (values and positions inthe SML tree for example) is created with the following properties.First, it may hold U≦s, so that the subtree below s is touched by theupdate. This may be performed because old SML tree nodes n≦U strictlybelow U, i.e., n/εU are invalidated by the update, and may not beverified anymore with respect to the updated root verification dataregister. Second, U is dependency-free, i.e., u,u′εU:u≦u′.

Dependency free is a property ensuring consistency of the tree update byU with the one-way (upward) information flow embodied in Merkle hashtrees. In particular it makes the update result independent of the orderin which elements of U are processed.

Phase 5 is the SML tree update proper. Iterating over uεU,TPM_Tree_NodeVerified_Update is called with arguments (u,n,u,R(n)),where n is the old SML node value at position

u

. This returns the new trace T(u) with which the TSS updates the SML.Executing the tree update in the way described above maintains aconsistent security level for the SML and root verification dataregister. Namely, the operation ⋄ is executed inside the TPM. When Ucontains many elements, it may not be efficient to perform the update inthe way described for Phase 5, since TPM_Tree_Node_Verified_Update wouldin such a case verif_(y) many overlapping reduced trees and thus incurredundancy in (complex) hash calculations. A more efficient updatealgorithm is described below, called “Efficient Secure Node Set Update”.

As mentioned above, updating a large set U of inner nodes may beinefficient using TPM_Tree_Node_Verified_Update, since many redundanthash operations for verification may occur, depending on the overlap ofthe reduced trees of the elements of U A bulk update strategy may beapplied to improve the naïve algorithm of Phase 5 of the subtreecertification protocol, using the TPM_Tree_Extend command describedabove. It rests on the observation that subsets of the update set U spansubtrees which are independent of the old SML values, i.e., their rootsdepend on nodes in U Thus the roots of the trees spanned by such setsmay be pre-calculated without expensive verification.

Some definitions are provided. Assume U={u₁, . . . u_(k)} is adependency-free update set. A node in the SML tree is calledU-intrinsic, if a) it is an element of U, b) its sibling is in U, or c)its sibling is U-intrinsic. This recursive definition captures nodeswhose updated values depend on U and not on SML nodes in the complementof U The span root of a subset V⊂U is the unique intersection point ofthe traces of all elements of V. The subtree spanned by a subset V⊂U isthe union of traces of elements of V with nodes strictly above the spanroot omitted. The subset V is called U-intrinsic if all elements of itsspanned subtree are U-intrinsic.

With these settings, more efficient update of the SML with U is done asfollows:

-   -   1) Identify the (mutually disjoint) U-intrinsic subsets V₁ . . .        V_(k) ⊂U.    -   2) Iterate over V_(i), i=1, . . . k.        -   a. Normalize the coordinates of elements of V_(i) by            -   i) truncating the prefix given by the coordinate of the                span root of Vi, and            -   ii) post-fixing zeroes until all coordinates have equal                length, the depth of the subtree spanned by V_(i).        -   b) Order the elements of V_(i) alphabetically according to            their normalized coordinates, producing an ordered list            {tilde over (V)}_(i).        -   c) Fill up all gaps (in the normalized coordinates) in            {tilde over (V)}_(i) with nil values.        -   d) Select a free verification data register V′.        -   e) Sequentially use TPM_Tree_Extend on the elements of            {tilde over (V)}_(i) with target V′.        -   f) Remove V_(i) from U.        -   g) Insert (V′,            v_(i)            ) into U, where v_(i) is V_(i)'s span root.    -   3) For the remaining elements of U, apply the normal update        procedure of as described above using TPM        Tree_Node_Verified_Update.

A variant of the subtree certification protocol may combine the roles ofPCA and SCA for AIK, respectively, subtree certification in a singleprotocol run. An advantage would be that no explicit generation andverification of an AIK certificate C_(a) may be necessary, becausegeneration, activation, and use of the AIK are bound into one session.This combination of protocols is straightforward.

Binding the received subtree certificate to the platform state meansbinding it to the tree-formed SML in the correct configuration, i.e.,the position of the certified subtree's root. As mentioned above, thisis essential for meaningful subtree certificate-based validation in thecontext of an overall platform configuration. One particular goal ofbinding the C_(s) to the SML tree is integrity protection, since, forexample, later replacement with a different certificate may beprevented. The binding may be achieved by updating parts of the treewith data which uniquely and verifiably identifies the subtreecertificate. A wide range of data items may be produced from the subtreecertificate and entered into the SML tree in various positions.

In one example the SML update may be trivial and U may be empty. Thismay be possible if a is composed by the first option of described above,revealing s. Then s may be retained in the SML tree and whether thesubtree below it is also retained depends on the use case. The bindingassociation is via the actual node value s signed by C.

As another example, consider the case that data concerning the platformproperty attested by the certificate may be protected by the updatedtree, e.g., for forensic use. That is, the three data items s, Ms, andCs may enter the update set. While the node value s is already in thecorrect data format, the other two are first processed to m(M_(s))) andm(C(s)). The operation m may be the generation of a hash value by theplatform's Root of Trust for Measurement (RTM), or another appropriateone-way operation. If some data item already contains suitable, uniquelyidentifying data of the appropriate node value format, then it may bedirectly extracted and used as node update value. A particular examplemay be a certificate fingerprint contained in C(s). The three updatenodes may then be configured in an update set to produce, for example,the configuration of updated nodes in the SML tree as shown in FIG. 27.

The root of the updated subtree is inserted in the old position of s andhas the value k=(m(C_(s))⋄m(M_(s)))⋄s. This configuration providesindependent integrity protection to the subtree certificate andmanifest, and retains the old node value independently. Attestation tothe platform property represented by C_(s) may, in this configuration,still be done without revealing information about s, by quoting only theleft inner node * of the subtree.

Variants of certificate to subtree binding abound. The platform may alsowant to include (integrity protection values of) own generated datatherein, for example an internal time stamp from a secure clock.Implementation here may be use case specific.

For the attestation of the property represented by a subtree certificateto a validator, the platform may quote, using TPM_Tree_Node_Quote, anynode in or above the updated subtree which protects the intendedvalidation data, which comprises at least the manifest and thecertificate proper. The platform may then submit validation data asnecessary to the validator, at least all data needed for verification ofthe asserted property, again comprising at least M_(s) and C_(s). Thevalidation data which is already protected by the submitted quote doesnot, in principle, require additional integrity protection.

The validator may verify platform binding of the validation data.Proving this property, i.e., that the validating platform is the samethat performed sub-tree certification toward the SCA, may be nontrivial. One way to achieve it is to use the same AIK, a, in subtreevalidation as in certification. The platform may then also submita_(pub), and if necessary also C_(a) as part of the validation data.Whether C_(a) may be needed depends on the semantics of the subtreecertificate, i.e., SCA may already have checked the AIK certificate andC_(s) may state its veracity. According information may be placed in themanifest. Reusing the same AIK partially compromises privacy, and othermethods to solve the problem may also be considered.

One step for the use of subtree certification is the discovery ofsubtrees for which a platform may obtain certificates from a particularSCA. Without going into details of the interactions between platform,SCA, and validator, two categories of subtree discovery methods aredescribed below. The first one places the workload of subtree discoverywith the platform, while the second one assumes a “dumb” platform andplaces more load on the SCA.

In one example, the SCA sends some subtree discovery data to theplatform, in the simplest case a list of node values which it is readyto certify. The platform may search for these values in its SML tree andperform subtree certification for each identified node. This baselineprocedure suggests various refinements, in particular enriching thediscovery data and extending the discovery procedure to a negotiationprotocol between platform and SCA. For example, discovery data maycontain root node positions as conditions on certifiable roots, whichwould, in the case of an SML produced in an authenticated boot process,correspond to the fact that the components loaded during the build ofthe latter subtree are loaded at a defined stage of the platform startup.

Such conditions on absolute positioning of nodes may be difficult inpractice for complex platforms whose configurations may changedynamically. More refined conditions may therefore also express relativepositions of some, e.g., pairs of certifiable roots. The SC may stateexpressions, such as an expression saying “s is certifiable, if it ispreceded by r” for example (i.e., r may rely to the left of s in theordered SML tree). This may be interpreted to the end that a certainfunctionality is operational on the platform if another functionalitywas made operational before it.

A more fundamentally different variant of the model is that thediscovery data does not consist of subtree roots, i.e., inner nodes, butrather of leaf, i.e., measurement, values. A “bottom up” discoveryprocedure may require that the platform makes an “educated guess” aboutwhich inner nodes are certifiable, based on the received leafmeasurement values which the SCA asserts to know as trusted values. Onemethod is to find the set of span roots of subtrees whose leaves are allin the discovery data. The platform may then quote a subtree root andsend it together with its SML subtree to the SCA. In general, the SCAmay have to verify the SML subtree and decide if it is ready to certifythat root, since this may still depend on the order of the leaves. Insome cases, the platform may want to obtain a certificate for a subtreefor which the SCA knows some leaf values, i.e., the leaf set of thecorresponding subtree may have gaps with respect to the discovery data.If the platform has other trusted data, for example RIM certificatesobtained from a party which the SCA trusts, the platform may submitthese data in Phase 2 of the subtree certification, to aid SCA with itsdecision to certify the subtree root.

In the case that the device is not capable to perform a local discoveryof subtrees, an implementation may be used which moves the computationalto the SCA. The platform selects an inner node n, with the aim toretrieve certificates from the SCA for any suitable subtrees below n.The node n may be equal to the root of the complete tree (V), in thecase that the platform wants to get all certifiable nodes certified. Thenext two steps are the same as described in Phases 1 and 2 above, i.e.,the platform performs a TPM_Tree_Node_Quote, or TPM_Quote, respectively,if V was selected. An attestation package is wrapped together with theSML subtree below the quoted root. The SCA receives this information andmay then, using tree traversal techniques, verify the integrity of thetree and concurrently find one or multiple (disjoint) subtrees S_(i)with certifiable set of roots S.

The SCA then iterates phase 3 of the protocol as described above,creating certificates for all s_(i)εS. Since the protocol allows for theupdate of multiple nodes, incorporated into the update node list U, theupdate of all found subtrees may be done in a single protocol run. Avariant may be for the platform to not send a TPM_Tree_Node_Quote orTPM_Quote in the first step, but provide the SCA with the SML, startingfrom the selected node n. The SCA then searches for potential candidatesub-trees to be certified and then requests the platform to provide aTPM_Tree_Node Quote for the root nodes of the identified subtrees. Thisis a trade-off in the sense that it allows the platform to send the SMLwithout having to perform cryptographic operations in advance.Nevertheless, the platform may provide appropriate quotes prior to thecertification by the SCA to provide integrity protection for the sentSML.

Described above are systems, methods, and apparatus for implementingTFV. Described below are variants and/or extensions of TFV.

A method for a validator to traverse a tree-formed SML submitted by aplatform, may be by descending level by level as described above.Described below is a variant procedure in which the validator firstlooks for known good values of roots of subtrees in the SML tree, toidentify known good parts of the validated platform, before traversingthe SML tree for failed leaf components.

It may be difficult to keep reference trees of the SML trees of a wholeplatform. Such a tree may be large and depend sensitively on platformconfiguration, such as load orders of components for example. The treetraversal validation assumes a static measurement sequence indetermining that the diagnostic validation described therein identifiescomponents which do not conform to a desired reference configuration ofthe validated platform. In fact, since the Merkle-Damgard transform isneither commutative nor associative (it is not a multi-set hashfunction) the tree root values depend on the exact measurement sequence.Since the same holds for linearly created PCR values, the performancecomparison described above is still fair. The problem oforder-sensitivity of the tree root is addressed further below. Themethods described there may be combined with the ones described here.

The state of affairs may, in a naïve solution, necessitate to maintainreference trees for effectively (functionally and with regard tosecurity) equivalent configurations of a platform. Thus, a finer-graineddataset for validation, than complete reference trees may be desired.

Instead of keeping a database of known good values of roots of SML treesand corresponding reference trees, the validator keeps an extendeddatabase of known good subtree root values of subtrees of variousdepths. These values are stored as pairs (r,d), where r is the nodevalue of the subtree root and h is the depth of the subtree. The depth dranges from the depth D of the full SML tree to 0, where d=0 means thatthe corresponding known good reference value is actually a leafmeasurement. When reaching a certain level L in diagnostic treetraversal, and after cryptographic verification, the validator compares,by breadth-first search, the node values of the received SML tree atthis level to the known good values {(r,d)|d=D−L}. The subtrees withmatching roots are marked as known and excluded from further diagnostictraversal, which then proceeds with level L+1.

Keeping a database of known subtree roots also allows for a differentvalidation strategy, as opposed to descending the tree from the root,for the validator. The validator may look, by any search procedure itdeems efficient, for (a subset of) known good subtree root values in theSML tree. Then the validator may verify the integrity of these subtreeroots. For this the validator may use the reduced tree of the subtreeroot node and the verification procedure for this value describedelsewhere. If the value is integrity verified, then the correspondingsubtree may be marked as OK, and omitted from subsequent diagnosticvalidation.

Identification of known subtrees as such leaves room to differentconfigurations of a platform, in particular different load sequences ofknown components and failed components. For example there may be twosubtrees A and B with 8 measurement leafs each which have anothersubtree containing failed components between them. If the validatoridentifies A and B as known, but normally would accept them in sequenceB, A, and in immediate sequence, or with another known subtree C in themiddle in sequence A, C, B then the validator may have to decide basedon policy whether to accept the platform configuration as valid.

As an extension of the described variant, the validator may dynamicallyfeed the reference tree database by interactive learning based onprevious platform validation results. One possibility is to performdiagnostic validation the first time a platform validates, and generateknown good subtrees from subsequences of leaf measurements whichcorrespond to a good platform configuration according to the validatorscomponent (i.e. leaf) trusted reference values and policy, as mentionedherein. When more and more platforms validate, the validator may build astatistically weighted database of known good subtrees and platformconfigurations according to criteria such as commonality and risk(associated with configurations). Commonly appearing subtrees may besearched for first, for example.

The described method is similar to the subtree discovery methodsdescribed for the subtree certification method. It is a method that maybe applied, together with or separate from a learning strategy, by theSCA entity.

The method for a validator to traverse a tree-formed SML submitted by aplatform, is descending level by level. For this, the whole tree issubmitted in one communication step to the validator and evaluatedagainst a reference tree. Here an alternative embodiment is describedwhich sequentially transmits the tree nodes at the various levels, oneby one.

The whole SML tree may be submitted to a validator. This may not beoptimal in general, in particular when the ratio of failed leafmeasurements is small. Then, many sub-trees would be transmitted as partof the whole SML tree, but their contained node data may not be used forvalidation, since their subtree roots are correct with respect to thecorresponding node in the reference tree.

The basic approach to minimize transmitted data in TFV is to transmitonly such data to the validator, that is actually needed for the currentstep in tree-traversal validation, as described elsewhere. The validatorfirst receives the root verification data register of the SML tree andevaluates it as level L=0 of interactive tree traversal validation. Ifits value coincides with the root of the reference tree, validationends. Otherwise, the validator requests the two child nodes of the rootfrom the platform. After receiving them, the validator either detects anintegrity failure condition c) in FIG. 9 described herein and stops, orrecalculates the root from the children. The message containing thechild nodes needs, in principle, no cryptographic protection forintegrity nor for freshness, since its contents are verified withrespect to the parent node by recalculation of the extend operation. Theroot, in turn was assumed to be transmitted with protection by aTPM_Quote or similar operation, e.g., a digital signature.

Comparing the two children at L=1, the validator may find which of themare correct with respect to the reference tree. They are discarded fromfurther search. The validator then requests the children of all ‘bad’nodes at tree depth 1 (that is, either 2 or 4 child nodes at tree depth2). For each of them, verification and reference tree comparisonproceeds as before. The procedure continues by iteration. In this way,the bad inner nodes needed to find failed leaf measurements are actuallytransferred to the validator. As mentioned, this may be done veryefficiently with short message sizes and without cryptographic overhead.The amount of data relative to the size of the tree-formed SML dependson the proportion of failed leaves. It is shown in FIG. 10 describedherein.

There are various combinations of tree-formed verification data withother methods for TFV's suitability: First, to provide validation datafor frequently changing, dynamic, platform (partial) states, and second,provide extensible space for verification data.

A PCR, or verification data register, is just one (hardware) protectedmemory space, and a platform is notoriously short of those. Hash trees,as described herein, lift this restriction in principle. But the securegeneration process of tree-formed SMLs with root protected verificationdata registers, e.g., PCRs, may lead to trees of fixed depth and thuslimited capacity for leaf measurements. A problem may arise when aplatform has more components to measure than fit into its tree-formedSMLs.

Another problem may arise if verification data protects records of afrequently changing, partial platform state, such as a memory region.The hardware protected operations which update a PCR value, theTPM_Extend operation, are slow. Thus a PCR is not suited for protectionof frequently changing data. PCRs may thus be unsuitable for directruntime memory protection. Various systems employ Merkle hash trees forthis, but their roots are normally not stored in hardware-protectedregisters, since their update would be too slow to keep pace with theplatform's dynamics.

The basic idea employed to protect a dynamically changing platformstate, represented by some data W(t) depending on (discrete) time t, isa cache-then-update strategy for an associated verification dataregister R. Some trusted software APP_R protects this state sequence inR. APP_R collects intervals of states W(kL+1), . . . , W((k+1)L) oflength L, caching them before measuring them with a digest function andextending them into R, using the PCR extend operation or a similarchaining operation, e.g., based on a Merkle-Damgard transform.

Various heightened security requirements apply to APP_R. In particular,sufficient protection is applied to APP_R against modification andtampering must be applied (methods are known, e.g., virtualization orintegration into security kernels). Furthermore, the operation of APP_Rmay be open to assessment by an external validator. A minimumrequirement for this may be that the trustworthiness of APP_R isverified, for example during secure start-up, registered, by measuringAPP_R before load, and bound, in a way which is verifiable by thevalidator, to the actual sequence W protected in R.

A method providing the desired features is as follows. The sequence W(t)may be cut into intervals of length L:

$\underset{\begin{matrix} \\{{length}\mspace{14mu} L}\end{matrix}}{{W\left( {{L\left( {k - 1} \right)} + 1} \right)},\ldots,{W({Lk})}},\underset{\begin{matrix} \\{{length}\mspace{14mu} L}\end{matrix}}{{W\left( {{Lk} + 1} \right)},\ldots,{W\left( {L\left( {k + 1} \right)} \right)},}$

And a digest function is applied to the partial sequences to produce aninterval measurement value: M_(k)=m (W(L(k−1)+1)∥ . . . ∥W(Lk)), k>0 Asa variant, it may be useful to incorporate time-stamps coming from asecure source, in the interval measurement, for example as:

M _(k) =m(W(L(k−1)+1)∥ . . . ∥W(Lk)∥TPM_Tick(now))

Adding timestamps to intervals of measurement values allows reorderingof (sub)-structures without losing information on the load order ofcomponents. Furthermore it allows ‘aging’ of measurements, where avalidator can request the renewal of measurement values after a giventime period. The interval measurement values are protected by extendingthem into a verification data register for instance by the extendoperation: R(k+1)=R(k)⋄M_(k+1) resulting in a sequence similar to anormal, linearly chained SML

in which intermediate states are also protected in the SML, i.e., theSML protecting W looks like:

SML _(W) ⊂[R _(init) ,R(0),M ₁ ,W(1), . . . ,W(L),R(1), . . . ]

The desired binding to the trustworthy state of the managing applicationAPP_R may be achieved as follows. A secure or authenticated bootfacility of the platform measures APP_R before load and extends themeasurement value m(APP_R) into a verification data register Q (whichmight be initialized with the value of a preceding PCR P in a transitivechain of trust). Then, the sequence of the actual recording register Ris initialized with P and an initialization value R_init, for instance asession nonce or a time-stamp, or both. This results in a structure

If there is a shortage of verification data registers, P, Q, and R maybe one. Verification proceeds on the extended SML for W which maycontain:

[(W(Lk+1), . . . ,W(L(k+1))),M _(k+1) ,R(k+1),R(k), . . . ,/R(0),R_(init) ,Q,m(APP _(R)),P]

and a quote of P, Q, and R. If present, the SML may also contain thevalues of time stamps.

The actual hardware-protected verification data registers may bedecoupled from the root of tree-formed SMLs, which may then be stored inless protected memory spaces but are protected by the former ones. Forthis, special software TFV_APP manages hash trees protected by a root W,which may still be an ordinary memory space, in an internal tree ofdepth d, with leaves V_1, . . . , V_(2̂d−1). The state sequence of W(t)is in turn protected by a hardware protected, actual verification dataregister R, for example by using the interval method of the lastsubsection. The virtual registers V may then be used as roots of SMLtrees and are managed by TFV_APP. For them, TFV_APP may expose thecommands described elsewhere to external applications, as if they wereroot verification data registers. The structure of R is as before:

while the coupled Ws represent tree roots as shown in FIG. 29.

Verification of a V_(i)(t) may extend over the following verificationdata:V_(i)(t),R(V_(i)(t)),W(t),R_(N+1)(t),R_(N+1)(t−1),R_(N),R_(N−1),m(TFV_APP),Q({R_(N−1),R_(N),R_(N+1)})where Q is a quote of the PCRs R_(N−1), R_(N), R_(N+1), and proceedsaccording to:

i. Check V_(i)(t) w.r.t. its reduced tree R (V_(i)(t)) and the root W(t)

ii. Check R_(N+1)(t)=R_(N+1)(t−1)⋄W(t) according to (2)

iii. Check R_(N+1)(0)=R_(N)⋄W(0) if additionally R_(N+1)(0), W(0) aretransmitted

iv. Check R_(N)=R_(N−1)⋄m(TFV_APP)

v. Check m(TFV_APP) against reference values

vi. Check the quote Q.

Additionally, time-stamps may be applied as described above. It isassumed that binding of TFV_APP occurs to the root R_(N+1) similarly as:

where W(0) is some initialization value.

The secure formation of SML trees has a natural capacity limitation. Amethod to lift this limitation is a simplified profile application ofthe subtree certification method above. An SML tree of a certain fixeddepth is filled up completely, the platform (self-) certifies the treeand inserts the obtained certificate as first measurement into the next,empty SML tree. This results in a left-unbalanced multi-tree structureas shown in FIG. 28.

A register V may protect the root of the tree-formed SML, SML_1. Astand-alone way to continue securely with the next tree is as follows.The platform calls TPM_Quote(V,a_1) to obtain a signed statement Q_1using the AIK a_1. The TPM_Quote represents a signature command that maybe executed inside the TP's TrE (e.g., by the TPM) on the designatedverification data register V. Thus, Q_1 asserts to any verifier, uponverification of the signature and the PCA certificate of a1, that thevalue V was once contained in the verification data register V. Theplatform saves the augmented SML_1:

SML_1*:=SML_1∥V∥Q_1∥Cert_PCA(a_1), that is, the original SML_1, thevalue of its root, the quote, and the according AIK certificate, forlater verification. The platform resets V. By the properties mentionedabove, SML1* is semantically equivalent to SML1 and the register Vcontaining its root. The register V is now free for the next tree build.

Subsequent trees may be bound to previous ones to assure continuedinternal verification by the root of trust in charge, i.e., a continuousassurance of integrity for contained leaf measurements. One exemplarymethod for this is to start (for instance by way of a modification ofthe platform's RTM) the next tree, SML_2, with a first measurement valuethat binds to the last tree. Various examples for doing this aredescribed below.

For example, the last root value V may be used directly as firstmeasurement. This may not preserve sequence of events, since then thenext tree does not contain any hint to the semantics of the appliedcertification of the last tree. According to another example,measurement m(Q_1) may be used as first leaf of SML_2. According toanother example, m(V∥(Q_1)∥Cert_PCA(a_1)) may be used as first leaf ofSML_2. According to another example, m(SML_1*) may be used as first leafof SML_2.

The last three options may be semantically equivalent, but are ofdifferent practical import, in terms of verification and/or generationcomplexity. The certified continuation of tree-formed SMLs mayiteratively continue without limitation. Instead of the internalcontinuation by certification, a trusted third party may be invoked tocertify the SML_1 tree.

The certified continuation of a tree may be extended with additionalsemantics by the TTP invoked. In particular, if the SML 1 is submittedalong with root certification request and verified, i.e., consistencychecked by recalculation of root. Then, a hash value of the SML_1 maydirectly be embedded in the certificate obtained from the TTP. Thisprovides a validator later on with assurance that the SML_1 wasuntampered with when submitted for TTP certification. This makes rootvalue V of SML_1 obsolete, in principle. The validator needs to verifythe global hash over the SML_1 blob, and the signature of the TTPcertificate over it, to check the integrity of SML_1. This isadvantageous since it means, for a validator who wants to use areference tree on the SML for tree traversal validation, that norecalculation of hash operations of inner nodes may be necessary, directcomparisons with reference tree nodes may be used. This may expedite thesearch for failed components. As further variants, TPM tick-stamps orTTP time stamps may be added to the certification.

Some methods and options to bind more expressive validation data intothe verification data of a tree-formed SML are described below.

By itself, the expressivity of an SML of any structure is limited tobare measurements of component code and data. In general, this does notyield enough information to a validator to handle validation efficientlyand manage a platform effectively according to validation results. Forthis reason, TCG enriched notions of SMLs to event logs recording alsocomponent identifiers, load time, parameters and related information,and TCG IWG introduced the notion of an (actually tree-structured) IML,a complex, expressive data structure to capture associated informationgathered in authenticated boot.

Such enriched and structured validation data, however, may lack bindingto verification data of an appropriate associated structure, such astree-formed SMLs. In particular for tree-formed SMLs the questionarises, how contextual information about components and platformproperties, or other useful validation data, may be securely bound intothe hash tree comprising the actual verification data.

In the actual measurement process, i.e., during the start-up phase ofthe platform, meta-data may be added to the validation data and bound tothe SML tree essentially by establishing a small subtree for themeasured component. One example realization (however, regarding amultitude of component and their measurement leaves) is described above.The measurement process, in the context of TFV, may be extended asfollows to include meta-data in the SML tree.

1. The agent performing measurement and SML building (identical to orco-operating with the RTM), loads a component measurement manifestcontaining prescription on which data has to be gathered and included inthe SML tree for this component.

2. If the next leaf in the SML tree is a right sibling (the leastsignificant digit of its binary coordinate is ‘1’), the agent writes onenil to the SML tree and protects it using TPM_Tree_Extend. This ensuresthat the component starts a new, separate subtree.

3. The agent measures the component itself and writes the measurementvalue to the SML and extends it to the root PCR using TPM_Tree_Extend.

4. The agent iterates over the manifest and, for each entry: Gathers themeta-data required; Appends it to the validation data sequence; Takes ameasurement of the meta data, e.g., a cryptographic digest; Inserts thismeta-data measurement into the SML tree, and; Extends it to the root PCRusing TPM_Tree_Extend.

5. The agent fills up the subtree for the component by appending nilvalues until the length of the measurement sequence for this componentreaches a power of 2.

This obtains a component subtree structure of the form shown in FIG. 30,where m(.) denotes the appropriate measurement function (which may bedifferent for various forms of meta-data).

Meta-data measurements may be inserted at other places, e.g., innernodes. The insertion of meta-data may be procedurally decoupled from themeasurement process, which may be useful for example to expedite thestart-up of the platform. Then, meta-data may be gathered by a differentprocess and securely stored (applying at least some form of integrityprotection) until its insertion into the SML tree. The Measurement agentprepares enough free space in a subtree, by filling it with nil values,according to the number of elements in the component measurementmanifest. After completion of the tree-formed SML with bare componentmeasurements during start-up, the meta-data may be measured and theninserted into the appropriate places usingTPM_Tree_Node_Verified_Update_command.

Some useful species of meta-data that may be included in a componentsubtree and describe their potential usefulness are described below.

Component identifier: A component identifier, composed for example ofcomponent manufacturer, name, version, build, release date, etc., may bethe most basic meta-data to include. Although in principle themeasurement value of the component itself identifies it uniquelyalready, an independent identifier adds semantics in a non-trivial way.It asserts that the platform attempted to load the named component,independently of the measurement outcome. Thus, in particular ifcomponent code or data was compromised, this provides independentinformation to the validator about which component thus failed integrityverification. This information is very useful since it allows findingthe correct TRVs for the component in question It is useful as an ordercriterion for components for the methods described above. An event logor IML according to TCG standards may already include componentidentifiers, but they are not normally protected by verification data.Here they may be bound to verification data of the SML tree and thusobtain a higher assurance level by the provided integrity protection.The component identifier may already be in a format (for instance astring of 160 bits) for inclusion, or may be measured to obtain thisformat.

RIM certificate: An appropriate identification of a TRV may be usefulmeta-data to bind to the component's SML tree. It may be realized forexample as the fingerprint of an according RIM certificate. It may beused, for example, (by the validator) to find according to the propercertificate, the contained RIM (TRV), either in an own database or via aTTP, or to obtain certificate status information. In this case, the RIMcertificate proper need not be incorporated in the platform's validationdata and may not be transmitted to the validator. If the platform'sstart-up process is secure, e.g., is realized as a secure boot process,then inclusion of according RIM certificate information acquiresadditional semantics. Namely, it asserts that the TRV certified by thatparticular RIM certificate was used for comparison with the component'smeasurement value. In this case, the actual measurement value of thecomponent may be obsolete in the tree-formed SML, depending onrequirements on forensic evaluation, for example.

Component context: The component context may comprise a description ofthe runtime environment into which the component is loaded.

Time stamp: A protected time stamp added as metadata adds context to themeasurement by providing the validator with the load time of thecomponent. This allows the validator to verify the load order ofcomponents, which may be of importance if component dependencies have tobe validated. It also allows assessing the freshness of a singlemeasurement, and if the data structure allows for it, the validator mayrequest a new measurement of the component. This may be done based on ameasurement aging process, where measurements may have a definedlifetime, after which validators may request a new measurement of thecomponent. Furthermore, applying individual timestamps to a measurementallows re-ordering of the structured data and enables the validator toderive the original boot-loader.

Component start parameters such as runtime/lead-time settings that maybe set differently according to the current condition of the device oroperating environment.

Component security policy: When there is an enforcement entity includedin the platform, the security policies associated with each componentand enforced by the entity are important data to the validator to assessthe platform's trustworthiness. By organizing a component's measurementsand meta-data in a subtree, validation thereof may be delegated to a TTPsuch as an SCA as described above for the subtree certification method.

Geo-location information at the time of component invocation addsanother dimension (location) to the expressiveness of the measurements.This metadata field may be useful especially for moving devices, whichchange location often and where applications may also be locationdependant (e.g. asset/cargo tracking reporting software). Instead ofreporting that a component was measured at a specific time this may alsoinclude a location where measured.

For practical realization of TFV, the component subtree may contain datathat is mostly of ‘static’ nature, to avoid the recognition problemdescribed below. If desired meta-data includes frequently changing data,or data which is rather individual to a platform, it may make sense toreserve, for such data, a completely separate SML tree, protected by itsown root verification data register, or a designated subtree of thecomponent SML tree. The positions in such an ephemeral meta-data SMLtree may be bound to the original SML tree simply by order, byrepetition of the component identifier, or component measurement leaf,or by any other means to link the ephemeral meta-data SML tree'scontents to the according component subtrees in the original SML tree.

Like linearly chained SMLs and resultant PCRs, tree-formed SMLs and rootverification data registers are sensitive to small changes of thesequence of measurement values. Thus, a problem arises in efficientlyrecognizing known tree and subtree roots, since their values depend onexact measurement leaf order. Different possibilities to approach thisproblem are described. They consist in measures to organize themeasurement leafs according to an order known to platform and validator,thereby reducing the combinatorial complexity stemming from sequencesensitivity. Methods and technical procedures to organize leafmeasurements according to technical criteria for efficient TFV are alsodescribed.

PCR values resulting from a Merkle-Damgard transform, i.e., combiningresults of one-way functions by a non-associative and non-commutativeoperation, are very sensitive to the order of inputs. This principle, isdesirous from a security viewpoint, and a feature of thistransformation, reflecting the ability to detect the smallest changes ininput data. The property holds likewise for tree-formed and linearlychained SMLs and root verification data registers, respectively, PCRs.This information preserving feature of the Merkle-Damgard transformentails complexity when it comes to interpretation of the containedinformation.

The sequencing complexity problem shows itself particularly in TFV, whena validator attempts to assess a platform according to a submittedtree-formed SML. A generic tree-traversal procedure for the search forfailed components is discussed herein. It showed to be efficient whencompared to evaluation of a linear SML even for high proportions offailed (i.e., unknown to the validator) leaf measurements. However,failure in this validation model may also result from modifications orsequence failures, i.e., measurements appearing in an unknown, withrespect to the reference tree used by the validator, position. A singlepermutation of two known measurement leafs produces two unknown ones.Insertion or omission of a measurement leaf at a certain positioninvalidates all following ones, i.e., leaf positions to the right ofthis position. Without due consideration of this problem, the efficiencygains of TFV may be lost.

In fairness, this is not really a problem when compared to linear SMLs,since they suffer from the same order sensitivity, and tree-formedvalidation is not more complex and/or computationally costly than thelinear case. For the resulting PCRs of linear SMLs the same problem mayemerge as a requirement to keep reference PCR values for allpermutations of input measurements, i.e., as spatial complexity. TFV, onthe other hand, may lose part of its advantageous features by thesequencing problem.

Merkle hash trees may be used for the run-time verification of memoriesin various research and demonstration systems. The sequencing problemdoes not appear there, trivially to the static assignment of memoryaddresses to leaves of the memory protection tree. To restore, if onlypartially, such an order known to both platform and validator, is oneidea behind the methods described below.

The problem under consideration is of an information-theoretic nature,as it regards an asymmetry of information between the platform (sender)and validator (recipient of tree-formed validation data). The sequenceof measured components is the piece of information that may be sharedbetween those two parties in an efficient way, where efficiency means inparticular that the validator neither has to keep a too large databaseof reference validation data (SML trees), nor that the validator isrequired to do costly, on-the-fly pre-calculations.

Efficient pre-sharing of information is one method to meet requirementsdescribed. For this, coding will be employed by platform and validator,established through conventions which both follow in the TFV process.The methods described below include realizations of this generalstrategy. The methods described below are not restricted, inapplicability, to the case of tree-formed verification and validationdata. They may also directly apply to the traditional case of a linearSML, though the benefit they bring there may be limited. The efficiencygain by conventional sorting of verification data for platformvalidation increases with the inherent structuring of the latter data(presuming that sensible realizations of verification data would beorder-dependent). Thus, ordering methods may be applied to otherstructures such as (directed, acyclic) graphs, or annotated skip lists(which are also optimized structures for rapid search).

Besides ordering methods described, there is another approach to theproblem of recognizing verification data by the validator. Namely, thevalidator may learn typical platform configurations over time. This maybe less effective for platforms with frequently changing configurationsand less frequent validation, such as personal computers, for whichconfiguration may differ for practically every boot cycle, or weeklyupdates are common, while re-connection to a corporate VPN occurs onlysome days in a week for a remote workplace. The configuration of such aPC, transmitted via its PCR values, and attested to the network viaremote attestation and additional protocols such as TNC, may bedifferent each time. On the other hand, mobile devices, M2M Gateways,and special embedded devices like HeNBs and multimedia STBs have morestatic configurations, and concurrently connect to the networks—and thusvalidate more frequently. Also, updates on them are managed by networkentities which may keep track of the known device configurations. Forsuch devices, it may suffice if a learning strategy for deviceconfigurations is applied by the validator. For example, a validatorreference SML tree may be built at first validation by the device fromknown TRVs (e.g., RIMs with according certificates). Such a tree may notactually be used as reference for devices with the same configurations.Subtrees of these learned reference trees may even be found, byidentification of their root values upon first validation of anotherplatform, and appropriately used for validation and composition of newlylearned reference trees.

There are two fundamental options to provide the desired ordering totree-formed SMLs. Either, a known order is applied before themeasurement is effected by the RTM (pre-ordering), which results in arigged SML formation, or the measurement process is left untouched andordering is applied later, on the completed SML tree, in a secure way(post-ordering).

One realization of pre-ordering changes is the actual load sequence ofprograms so as to conform to a given SML sequencing. If this is feasibleon a particular platform, it may leave the secure start-up andmeasurement process otherwise undisturbed. Another option, is to storethe measurement sequence in a secure cache and inserting them into theprotected SML tree only after the platform's start-up. This methodhowever may require a secure transfer of measurement values into thecache, where they may then be integrity protected until all measurementsare performed. Afterwards, the ordering operations may have to act onthe stored data without allowing modifications to them. Hence thisoption may have additional requirements, which if not met properly mayintroduce security weaknesses.

Post-ordering is interesting as it allows for ‘lazy execution’ as abackground task while the system is already operational. The timerestriction that applies is that the SML may be ordered, when it is usedfor validation. Since there is now a direct way to securely shuffle theleaves of a tree-formed SML, post-ordering may operate on a second,empty SML tree, protected by another root verification data register.The steps applying for the build of this post-ordered SML tree from theoriginal one are executed by some trusted agent on the platform and areas follows. The post-ordering agent iterates over the sequence ofcomponent identifiers for the desired SML sequence and: 1. Identifiesthe leaf position of the next identified component (for this,identifiers of the actually measured components are needed. They may berecorded in an event log for the measurement process or directlyattached, such as in digested form for example, as a sibling of thecomponent's measurement leaf). 2. Verifies the leaf measurement againstthe root verification data register using for instance the TPM_TreeNode_Verify command described elsewhere. 3. Upon success, inserts themeasurement into the ordered tree using TPM_Tree_Extend. And 4.Pre-ordering may not be feasible for all components of a platform, forinstance due to dependencies.

Extensive post-ordering may not be desirable, since it incurscomputational cost. So mixed forms of pre-ordering and post-ordering aresuggestive. Specifically, a subset of components of the platform may bepre-ordered, while another, presumably smaller, portion of componentsundergoes post-ordering after measurement. This may result in at leasttwo SML trees from measurement, which may then be joined to a fullmeasurement tree, for example by subtree certification.

While pre-ordering and post-ordering reside at the platform and areoperations executed before transmitting validation data, a third,different option is to impose some computational burden on the validatorto obtain the correct sequencing of the reference tree. For this, theplatform may transmit a sequence of component identifiers, indicatingthe sequencing of the measurements of the tree-formed SML or a subtreethereof. Alternatively, the platform may send the plain list of leafmeasurement values by which the validator may also be enabled touniquely identify the component at each leaf, if known. The validatormay then use the time lapse between receipt of this component identifiersequence and actual validation to build a reference tree in the orderthat is to be expected. This may require less hash operations thanbuilding the full reference tree of the platform, at least if theportion of permuted leafs is not too large. In this case, many subtreesof the platform's SML tree may already be contained in the validator'stree and may be reused. The task of the validator, upon receiving theordering information from the platform, is to identify the subsequencesof leaves which correspond to known subsequences and at whichcorresponding known subtrees may be inserted in the order-correctedtree.

This procedure may be effective if large parts of the full SML tree forvalidation are of fixed sequence by convention, and a smaller subtree isof unknown sequence to the validator. In this case the platform maysubmit the sequence of the subtree, and its position in the full tree,together with or before the full SML tree for validation, and thevalidator may build the subtree of unknown sequence from referencevalues and insert it in the correct position in his reference tree.

One implementation may apply lexicographic ordering of components,wherein the sorted data may be the component's reference measurementvalue, e.g., RIM value (not the actual measurement taken by the RTM,which may differ if the component is compromised). Another sortcriterion may be the unique identifier of a component or a digest valuethereof. This data may also be included in the tree-formed SML accordingto the method described above. A variant of lexicographic ordering is toassign an encoding to measurement values and/or other data and use theresulting code as lexicographic sort criterion.

Measured components may be ordered according to their failureprobabilities. To make this practical, the validator may define failureprobability classes for known components, for instance from failurerates estimated from a large population of validated platforms. Thecomponents of a certain failure rate class may then be communicated tothe platforms and then included into a reserved subtree for the latterclass. This may result in an SML tree which is optimized fortree-traversal validation, since it contains subtrees (withlow-failure-probability components) which are likely to be discardedfrom search in the traversal.

If there is a hierarchical organization of components of a platform,then measurements may be ordered accordingly. As an example, if theplatform is comprised of functionalities which consist of subordinatemodules, then a subtree may be reserved for functionalities and containthe measurements of their respective modules. Inside the subtreebelonging to a functionality, any other ordering that is applicable maybe used. In turn, the functionality subtrees may be ordered to combineinto the full tree-formed SML of the platform.

In a hierarchical organization of system components, for exampleaccording to a functionality module relationship, there may bedependencies which may affect the resulting measurement sequence. Aparticularly common case may be modules which belong (akin to a sharedlibrary or similar) to more than one functionality. Such modules may beloaded, and thus measured, once during secure start up of the platform.One way to capture such modules correctly in an SML tree organizedhierarchically by functionalities is as follows. The agent performingsecure start up may keep track of all loaded modules and thus may beable to identify repetitions—for example if a module identifier appearsagain in the prescribed measurement sequence. When building thehierarchically ordered SML tree, the agent, when hitting on a repetitionof a module, first seeks the place of first occurrence in the SML tree,then verifies the actual measurement value at this first occurrenceposition and then inserts it in the tree at the new position.

A special situation occurs when a platform loads components whoseintegrity is correctly verified (against a reference value), but whichis unknown to the validator. Inserting without order into an SML treemay result in a failed component, and placement failure of followingcomponents. If the validator and the platform share knowledge aboutwhich components are known to the validator, then the platform may beable to sort the unknown measurement values into a separate subtree,while the subtree of known measurements is prepared in an order known tothe validator. The two trees may then be joined for tree-traversalvalidation, for example so that the known SML tree is the left subtree,while the unknown component tree is the right one. The latter one isprepared, in the validator's reference tree, as an empty tree containingnil values. That lets tree-traversal validation proceed undisturbed forthe known (left) subtree.

The above-described systems, methods, and apparatus generate and use ahierarchical structure, such as a tree structure, for verification dataand validation. Described below are further embodiments for use of sucha tree structure in network validation.

Tree-Formed Validation (TFV) is an enabler for complex types of networkside platform validation. TFV is a realization of Structured Validation,which means use of structured data by a validator to assess the state ofa platform. The structure of data may reflect the structure of theplatform to an extent and thus aid validation. Structured Validation isan implementation of the abstract platform validation and managementprocesses defined in Platform Validation and Management (PVM) discussedelsewhere. Platforms that allow for an effective and efficient, remotePVM, exhibit a modular, hierarchical architecture. Categories of dataare introduced with which platform validation operates.

In describing PVM, basic notions of data transferred between a platformand a validator, and other entities facilitating platform managementfunctions, may be defined. Those may be divided into three categories,according to security related properties and semantic content.

There are the four categories of data for PVM that are created by aplatform and used throughout the PVM processes. They are intrinsic tothe validating platform. A different, additional category is the trustedreference data, which is used, to compare validation data to known goodvalues. It may reside at the validator for use in validation of aplatform, or inside the platform, where it may be used for securestart-up or be transferred as validation and/or management data to thevalidator. This is shown in FIG. 25 where interrelation between thenotions is depicted.

Verification data is data which verifiably identifies a platform state,or a partial state with a well defined level of assurance. VerificationData is generated internally in a platform in a verification process,for example during secure start up of the platform, and/or duringrun-time. One protection goal for verification data is integrity whichmay be maintained during its generation, i.e., verification, and atleast throughout a platform's operational cycle (e.g., boot cycle).Another protection goal is freshness. One way to define (and raise) theassurance level of verification data is to separate out part of theverification data as protected verification data with a specialprotection level, for example, by hardware protection, in which case thestorage space is called as a verification data register.

Verification data may require a protected binding, e.g., cryptographic,to protect the verification data. The strength of the binding and thestrength of the protection define the assurance level of theverification data. Some realizations of verification data andverification are the described below.

The SML may include a sequence of 160-Bit SHA-1 values generated in theauthenticated boot process from measurements of loaded components. Thesehash values uniquely identify the loaded component. The assurance levelof SML values may depend on: a security of the RTM that carried out themeasurement, and on the integrity protection of the SML, for instance byverification data registers, e.g., PCRs. A variant are tree-formed SMLsof TF V.

PCRs of a TPM paradigmatically represent protected verification dataregisters. One general method for the internal verification of a TS isauthenticated boot, and uses capabilities of the TCB to assess thetrustworthiness of loaded or started software or hardware components atthe time the TS is initialized, e.g., on power on. Authenticated boot isrealized by starting certain functions of the RoT and the TCB beforeother parts of the TS. These parts operate as a RoT for Measurement(RTM). This means that components that are started or loaded later on,are measured, i.e., they, and their status and configuration after startare uniquely identified, e.g., by forming cryptographic digest valuesover a (binary) representation of hardware components embedded code andloaded programs. According to the specific requirements, the measurementvalues may be stored in secure storage, e.g., PCRs, which form theprotected part of verification data.

Secure boot is an extension of authenticated boot. It is of particularimportance for devices such as set-top boxes or mobile handsets that mayhave some stand-alone and offline functional requirements. The commoncharacteristic of devices equipped with secure boot is that they mayoperate in a trustworthy set of states when they are not able tocommunicate assertions on their trustworthiness to the exterior, e.g.before network access. In secure boot, the TS is equipped with a localverifier (a verification entity) and local enforcer supervising the bootprocess, which establishes the combination of a Policy Enforcement Point(PEP) and Policy Decision Point (PDP) to control the secure bootprocess. The local verifier compares measurement values of newly loadedor started components with Reference Integrity Measurement (RIM) valueswhich reside in the TCB, or are protected within the TS by a TR, e.g.,they are located in protected storage space, and decide whether they areloaded, resp. started, or not. Thus, the system is ensured to boot intoa defined, trustworthy state.

In Secure boot, an extension of authenticated boot, the platform isequipped with a local verifier (a verification entity) and localenforcer supervising the boot process that establishes the combinationof a PEP and PDP to control the secure boot process. The local verifiercompares measurement values of newly loaded or started components withRIM values which reside in the TCB, or are protected within the TS by aTR, for example, they are located in protected storage space, and decidewhether they are loaded, resp. started, or not. Thus, the system isensured to boot into a defined, trustworthy state. The sequence of RIMsused in secure boot comprises the verification data. The measuredsequence may additionally be extended into a verification data registeras protected verification data. In this case, RIM certificates (moreprecisely their cryptographic fingerprints) are also protected parts ofverification data, with protection afforded by the TTP issuing them, andthe underlying certificate infrastructure.

An exotic variant of verification of a platform is proposed for WSNs bysome researchers and called ‘software attestation’. It consists inexecuting a probe code, sent by a remote validator to the platform,which checks the platform state, for example memory contents. In thetradition of zero knowledge proofs, the information returned to thevalidator as verification data may be the runtime of the probe.Obfuscation ensures, to a certain extent, that an attacker may be ableto produce the return signal after a measurable delay.

Distinct from verification data, validation data is the superset ofverification data of data that can be gathered and submitted to anotherparty, the validator, and used to assess the trustworthiness of thestate of the platform, in particular by checking it against containedverification data. The process of submission of validation data to thevalidator, for example realized as remote attestation according to TCG,and evaluation thereof by the validator, is properly called validation.Validation data may comprise verification data such as quotedverification data register (e.g., PCR) values. Validation may, beyondcryptographic verification of verification data, include policyevaluation and triggering of actions by the validator, using for exampleadditional management data which may be associated to the validationdata.

Similar to verification data, validation data identifies a full orpartial system state, but additionally provides more information to makethe validation efficient for the validator and determine the level ofgranularity of the validation result. Examples for validation data are:Named system properties such as generated by PBA, or names and versionsof components, their status and parameters, the platform certificate ofa TS, as defined by the TCG, and vendor certificates of systemcomponents; Names of TTPs, where further data may be fetched, e.g.,certificate chain information; Component-subcomponent relationships, forinstance captured in nested XML data structures, as specified by the TCGIWG; A platform identity for validation, called validation identity,realized, e.g., by an AIK key pair.

One aspect of validation is the binding of validation data to accordingverification data. This binding, in the spirit of transitive trustchaining, transfers the assurance level of verification data tovalidation data. Thus, this binding may be verified, for example by adigital signature. The notion of validation data may be restricted bythe requirement of binding. Validation data is such data which can beverified by the validator, in particular for data integrity, usingverification data. Thus, validation data is less arbitrary than generalmanagement data defined below.

Remote attestation is a realization of an initial stage of validation,namely the secure transmission of validation data to the validator,signed by the platform. In turn, an example of this binding is theTPM_Quote operation which signs a PCR value with an AIK. Verifying thissignature, and recalculating the PCR from the SML and associating theSML measurement values to RIMs of known components which are named inthe validation data, the validator may verify that the named componentsare the ones the platform has measured during authenticated boot, forexample.

Management data comprises and is supplementary to validation data. Itadds expressiveness to the other data specifically for management of aplatform based on validation data and results. The binding of managementdata to validation data is logical, that is, elements of management datalink symbolically to associated elements in the validation data, or viceversa. The trustworthiness of management data (for example by itssource) may be assessed separately from validation of the plat-form, inparticular if management data comes from a TTP.

Typical examples of management data are: policies which infer managementactions from validation results; places, where code updates can befetched from; incident reporting data; user notification data; servicecredentials provided to the validating platform conditioned onvalidation results.

Trusted reference data is data that is used to compare validation datato known good values. Those values, that constitute trusted referencedata, are called Trusted Reference Values (TRV). Their best knownexamples are RIMs, as specified in the TCG's MPWG specifications forexample. They may be used genuinely, a) by the platform itself in securestart-up, to ensure that components whose measurements conform to a TRVare started, or b) by the validator, to compare validation data to knowngood values and thereby assess the platform state in validation.

As such, trusted reference data becomes trusted through certain securityassertions about it, which are verifiable by the validator or the agentusing the TRV in question. Such verifiable assertions may be realizedfor example by digital certificates issued by a TTP, giving rise, in theconcrete example, to the so called RIM certificates. The trustassertions of trusted reference data may also contain additionalinformation for example about external evaluation (e.g. according to aCommon Criteria EAL) of a component or platform.

Split Validation describes a concept that allows distributing validationtasks between two (or more) networked entities. The idea is focused onthe validation procedure itself and not bound to a specificarchitecture. However, an architecture model is chosen to present thegeneral concept, mainly the architecture of a M2M device acting as M2Mgateway for M2M devices connected to it, with the M2M gateway beingconnected to the MNO's network. The concept itself is not limited tothat architecture and may be applied to different architectures, whichexhibit a certain hierarchical structure (e.g. HeNB and connectedUE/WTRU, clusters of devices with a master node in the cluster, etc.).

The general methods described herein, such as subtree certificationprocedures and/or discovery options are a base technology to implementsplit validation as described here.

A client-server model is assumed where a client C wants to access aservice S where the server provides the service to C if C is in atrustworthy state. The C may able to convey validation data v (e.g.measurement values) to S.

In this scenario, S may have tools to derive the state of C from thereceived validation data v, which is achieved by reference values r towhich S may compare v. The reference values r are not restricted toreference metrics which provide known good values for v. The referencevalues provide a mapping between the received data v and thetrustworthiness of the device. Hence, r may be seen as a mapping of v toaccess policies for the service, which means that r may be any kind ofreference, which allows S to derive a statement on the trustworthinessof C from the received V.

In some scenarios C may be connected to S via a gateway device G (e.g.M2M gateway, HeNB as gateway for WTRU). If G is able to perform initialparts of validation of connected Cs, i.e. G is equipped with r forconnected devices, the load for validation tasks may be distributedbetween G and S.

This distribution of validation between two networked entities isreferred to as Split-Validation. For Split-Validation to work, it mustbe possible for G to validate single connected Cs, and S may trust G toperform this validation in a secure manner. Furthermore, if thevalidation data v exhibits an internal (hierarchical) structure, it maybe easier to perform an efficient split-validation.

As one implementation of Split-Validation, entities may be able to useTree-formed Validation (TFV) data. G may be able to generate its ownstructured validation data. G may be able to perform tree updates,including removal and addition of subtrees. G may be equipped with ameasurement agent (MA), with MA being able to integrate validation dataof Cs into the validation tree of G. These subtrees may be certifiable(and hence validated and signed) by either G directly or by a TTP.

The MA inside G collects measurements from the connected Cs andintegrates them into the tree of G as new subtrees. The collection ofmeasurements may be performed during a local signify verification of theCs to G (e.g. by performing SAV, Hybrid Validation, Remote Validation onthe C-G link) or after authentication in an additional protocol step.This step may be bound to a device authentication of the Cs, to preventreplay and forged validation data. However, this authentication may notbe required to represent the authentication used by the Cs to access S(e.g. MNO credentials used to access the network), since thisauthentication may be performed in an additional step, when Gestablishes the connection to S for this specific C. This is shown inFIG. 31.

After collecting the relevant data, G contacts a TTP which issuescertificates for the subtrees to G. G is then able to incorporate thecertificates into its own validation tree, resulting in a new andup-dated validation tree. As a variant, the TTP may also be a part of G,e.g. implemented as an application which runs inside the TrE of G orintegrity protected by the TrE. This is shown in FIG. 32.

In the final step, G sends the updated validation tree including thecertificates replacing some or all of the subtrees for the connecteddevices to S. S may be decomposed for exemplary purposes into twosubunits, a Validation Entity VE and a Service Entity SE. While VE isable to validate the received data from G (either autonomously or withthe help of a TTP), SE is responsible for the actual service beingprovided to the Cs (and optionally services provided to G). In avariant, where G is not able to authenticate the Cs with the credentialsto access S, SE may also perform authentication, e.g. S may perform the3G authentication, while G authenticated the TrE in the devices toverify authenticity of the received validation data and device/TrEidentity of the connected Cs. This is shown in FIG. 33. After successfulvalidation, the service may be provided to C.

In Split Validation, G may preserve the privacy of connected Cs towardsS, since S may receive certificates, which replaces subtrees ofconnected devices. S may trust the TTP and the MA in G, where the trustin MA may be derived from the validation data received from G, since thevalidation data contains measurements of MA.

In a further variant, split validation may be extended to supportdynamic updates, including support for roaming Cs between different Gs,involving a handover of C-subtrees between Gs. Another variant for Splitvalidation is a partial validation of single Cs at the gateway G,replacing only parts of a subtree with certificates.

The methods and algorithms described herein allow for an efficientimplementation of the operations for Split validation. They enable theuse of split-validation, based on an extended version of a TPM whichallows the devices to build, report, update and quote trees or subtrees.Furthermore, algorithms provide for the efficient replacement of subtreenodes with certificates by subtree certification.

One issue in split validation is to determine which Cs may be validatedby the TTP (and hence replace their subtrees at G) and which portion ofthe Cs may be validated by S, i.e. which reference values are availableat the TTP which G can use to certify subtrees of connected Cs. Ingeneral, solutions to this discovery problem may be divided in threeclasses: TTP based, Gateway based, and Shared discovery.

The TTP based approach is suitable for Gs lacking the computation powerto perform complex analysis to find suitable subtrees for certification.In this approach, the TTP receives the complete tree from G and returnsthe results in the form of a set of subtree certificates for subtreesthat the TTP can verify. The TTP may then discard the remaining datawhich it cannot certify. The certificates are sent back to G with anindicator as where they fit in the tree. The MA at G performs aningestion of the certificates, i.e. replacing the now certified subtreeswith the received certificates. G may not have to perform discoveryagain, since TTP passes indicators to the location of the subtrees inthe message with the certificates.

In a variant procedure, G does not transmit the complete tree, but apart of it to the TTP, allowing the TTP to search for potentiallycertifiable subtrees in a subset of measurements from attached devices.Such a mechanism may be useful, for example, if the tree-formedvalidation data exhibits a certain structure, which allows G todecompose the tree into subtrees based on certain device characteristics(e.g. device classes). Depending on the device class, different TTPs maybe able to validate a certain set of devices.

In the gateway based discovery, G has metrics to decide which Cs may becertified by the TTP and the TTP may receive the necessary data. Thisapproach allows a minimization of the amount of communication between Gand TTP, since all transferred data belongs to certifiable subtrees.However, G may be pre-equipped with suitable metrics, which may allow Gto discover the right subtrees and their TTPs which may certify them.Furthermore, in this method G may search its own validation tree forsuitable subtrees, putting more computational effort on G.

In a shared discovery model, the TTP and G make a joint effort todetermine which devices and hence subtrees may be certified. The resultof such a discovery step protocol is a list of subtrees that may becertified. This discovery protocol may include the exchange ofadditional (meta) data, such as device classes, capabilities, deviceprofiles, dynamic parameters, such as load and bandwidth. Despite theinitial communication needed to determine the set of certifiablesubtrees, this approach also minimizes the amount of data, since nounnecessary data is transmitted from G to the TTP. The communicationload may be more than in the gateway based discovery, but may be lessthan in the TTP based discovery. G may be able to store the outcome ofthe negotiation phase, which allows G to subsequently perform a gatewaybased decision. In the shared discovery model, G may be pre-provisionedwith a set of certifiable subtrees which may then be updated during ashared discovery phase.

In one variant, G fully validates some Cs, where the selection of Csmay, for example in the case of G being a femtocell, be based on CSG(Closed Subscriber Group). S then fully validates the remaining Cs. Theset of Cs to be validated at G may be based on static or dynamic dataand the set of devices to be validated by S would then be the remainingCs or may have an overlap, meaning that some devices may be validatedtwice.

G and S may validate aspects defined in aspect sets that may bepre-provisioned or dynamically adjusted and may have overlaps. Suchaspect sets may comprise: integrity of device profile, integrity of bootcodes/OS/drivers, integrity of capillary network functions/components,integrity of WAN connectivity functions/components, integrity ofhigh-level applications, and integrity of trusted reference values usedat G.

The validation may be split dynamically based on loading. In thisdynamic approach, G and S or G and TTP compare computational load onthemselves and on the links between G and connected Cs and between G andS or G and TTP. Based on the load, the TTP or S determine the sets ofdevices which may be validated directly at G. A pre-provisioned set mayexist, which is then dynamically updated.

In a knowledge-based split, the split may be determined between S (orTTP) and G based on knowledge sets and validation policies. Knowledgesets may include several factors, such as behavior (past observed, orpredicted for future), trustworthiness (past history, current value, orfuture predictions), cost versus benefit analysis, importance ofvalidating, etc. which may allow S and G to derive or update validationpolicies.

In one example, a H(e)NB may use Split Validation of a UE. For the HeNBcase, the architecture may comprise an H(e)NB being able to validatesome or all of the connected UE by the following procedure and shown inFIG. 34.

As illustrated in FIG. 34, the WTRU sends integrity measurements toH(e)NB at 1. At 2, the H(e)NB integrates the received data and validatessome (or all) WTRUs. At 3, SeGW/PVE perform validation of H(e)NB treeincluding connected devices. The PVE validates yet-to-be-validateddevices and issues a reference certificate at 4, which may be sent backto the H(e)NB to be included in future communication, e.g. enabling theH(e)NB to validate the WTRU in future connection attempts.

Another variant may be in a corporate deployment scenario, where theHeNB is able to validate a subset of the components of each WTRU, forexample corporate software, which may not be exposed to the MNO (SeGWand PVE). The PVE, may perform the network side validation of theunderlying platform components of the WTRU.

In the case of a rogue device connecting to the H(e)NB, the H(e)NB mayinclude the integrity tree of the UE for reporting purposes. The PVE ora validating network entity on the corporate network may be able toverify the received data and can then command the H(e)NB to block accessfor the device or engage in remediation steps, such as replacingcomponents or software, perform antivirus updates, etc. This is shown inFIG. 35.

Since the M2M architecture has some similarities with H(e)NB, Splitvalidation may bring some benefits to M2M scenarios. In a typical M2Mdeployment, smaller but more devices might be connected to a singlegateway, providing access to the network. Furthermore in M2M scenarios,a broad variety of different devices may be connected via a singlegateway, and hence the gateway may not be able to validate all devices(or all device types). Performing split-validation may allow the networkto offload some effort to the M2M gateway.

In a further variant, the M2M GW may group connected devices based ontheir type, device class, device properties, or connection profile(protocol, connection network, bandwidth) and then provide groupcertificates for the device validation trees. This is shown in FIG. 36.

Another variant is a Peer-to-Peer approach, in which multiple M2Mgateways (GW) exhibit a clustered structure, which may allow them tocommunicate over better links (e.g. more bandwidth, less latency, etc.).Each M2M GW has an own backhaul link to the network. However, localcommunication may be cheaper (e.g. via WiFi, Bluetooth, ZigBee, MBUS,etc), than using the backhaul link (e.g. 3G) which means that offloadingtraffic to the local network provides some benefit. The local networkbetween the M2M GWs is referred to as Local Area Exchange Network(LAEN). All M2M GWs on the LAEN may be mutually authenticated, whichallows M2M GWs to trust messages coming from other M2M GWs on the LAEN.The communication on the LAEN may be protected for integrity andauthenticity. In privacy demanding scenarios, a fully encrypted LAEN maybe established to provide confidentiality protection.

If an M2M GW is unable to certify a subtree (e.g. no TTP may be found tocertify the subtree or the device is unknown to the M2M GW), the M2M GWpushes out the subtree on the LAEN (step 1 in FIG. 37), with a requestmessage to acquire a suitable certificate. If another M2M GW is able tocertify the subtree (either on its own or via a TTP, which might not bereachable or not known by the first M2M GW), the M2M GW returns thecertificate to the requesting GW (step 2 in FIG. 37). The M2M GW maythen integrate the certificate in its own validation tree. The M2M GWcan also store the certificate (or reference values needed to create acertificate, or the address of the TTP) for future validation ofconnecting devices of the same device class.

The exchange of subtrees may be performed using the Tree Hash Exchange(THEX) format, which allows to exchange Merkle hash Trees. The exchangeformat consists of a serialized representation of the hash tree. It usesthe Direct Internet Message Encapsulation (DIME) format that allows formultiple payloads, either text or binary. The Merkle Hash Treeserialization format consists of two different payloads. The first isXML encoded meta-data about the hash tree, and the second is binaryserialization of the tree itself.

The localization of network entities on the LAEN, e.g. other M2M GWs,that are capable to validate a given subtree may use the DistributedHash Table (DHT) structure to store the network address of the node onthe LAEN that was capable to validate the specific device type or deviceclass. The DHT concept, known from P2P networks, allows for a fastdetection of the relevant nodes for validation. Furthermore it may bepossible to store the hash table at every node in the LAEN, and updateit via LAEN multicast messages between the nodes, such that every nodein the LAEN may know where specific subtrees can be validated.

The concepts and methodologies developed above for split-validation andother structured validation techniques such as subtree certification,may be used not just for system validation but also for othersecurity-related functions.

For example, in a split-authentication model for a network thatcomprises of the network entity NE, gateway G, and multiple devices D,it may be envisioned that the gateway G may, when it interacts with theNE so that the latter may authenticate it, include authenticationinformation about D so that the NE could authenticate the collection ofG and D at the same time. In a variant, the G could authenticate D's,and includes a report about that authentication step and results, in amessage that it later sends to the convey information that is needed bythe NE to authenticate the G. As described above, it may also bepossible to divide the D's so that a G may authenticate versus D's thatthe NE may authenticate, according to several different criteria.

Similarly, other security functions such as key derivation and keymanagement (including distribution, refreshing, and deprecation forexample), authorization, and access control, may also be done in similarways.

The techniques developed for sub-tree verification may also be used insimilar ways to these other security functions.

The methods, algorithms and apparatus may be applied to any technologyarea including: Security/Privacy/Rights Management, Hybrid Networks,Cooperative Communications, and may be used in/at—a User Equipment (UE),wireless transmit/receive unit (WTRU), Handset, Data Card,Laptop/Netbook, Gaming Device, Infrastructure Equipment, BaseStation/Node B, Femto base station, Access Point, BSC/RNC, Gateway,Application Server, System, Session Layer, Presentation Layer,Application Layer, DSP, Software, Hardware, ASIC. The methods andalgorithms are also applicable to: Applications, System Information,Platform Security, overall system Security, Call Admission, Home eNode B(HeNB), HNB, Femtocells, hardware or software implementation, chargingmanagement, Subscriber Management, Policy Control, Quality of Service(Qos), Security, Trust, Ciphering, Registration/AAA etc.

Although features and elements are described above in particularcombinations, each feature or element may be used alone without theother features and elements or in various combinations with or withoutother features and elements. The methods or flow charts provided hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable storage medium for execution by ageneral purpose computer or a processor. Examples of computer-readablestorage mediums include a read only memory (ROM), a random access memory(RAM), a register, cache memory, semiconductor memory devices, magneticmedia such as internal hard disks and removable disks, magneto-opticalmedia, and optical media such as CD-ROM disks, and digital versatiledisks (DVDs).

Suitable processors include, by way of example, a general purposeprocessor, a special purpose processor, a conventional processor, adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs),Application Specific Standard Products (ASSPs); Field Programmable GateArrays (FPGAs) circuits, any other type of integrated circuit (IC),and/or a state machine.

A processor in association with software may be used to implement aradio frequency transceiver for use in a wireless transmit receive unit(WTRU), user equipment (WTRU), terminal, base station, MobilityManagement Entity (MME) or Evolved Packet Core (EPC), or any hostcomputer. The WTRU may be used in conjunction with modules, implementedin hardware and/or software including a Software Defined Radio (SDR),and other components such as a camera, a video camera module, avideophone, a speakerphone, a vibration device, a speaker, a microphone,a television transceiver, a hands free headset, a keyboard, a Bluetooth®module, a frequency modulated (FM) radio unit, a Near FieldCommunication (NFC) Module, a liquid crystal display (LCD) display unit,an organic light-emitting diode (OLED) display unit, a digital musicplayer, a media player, a video game player module, an Internet browser,and/or any Wireless Local Area Network (WLAN) or—Ultra Wide Band (UWB)module.

Further work may pursue this direction and consider concretearchitectures for platform validation with tree-formed verification andvalidation data—what is called tree-formed validation (TFV). Oneconceivable option is to efficiently organize a database of referencetrees by an SCA and/or a validator in a way that allows for the modularbuilding using subtrees of known component substructures, e.g.,dependent programs loaded in sequence, or components with uniformassociated security policies. Architectures and methods for subtreediscovery, expression of dependencies between validated platformcomponents, and management (updates, remediation) of platforms accordingto results of TFV are subjects of ongoing research.

The systems, methods, and apparatus described herein may be implementedin a communication system, such as the communication system describedbelow, and as illustrated in FIGS. 38, 39, and 40.

FIG. 38 is a diagram of an example communications system 100 in whichone or more disclosed embodiments may be implemented. The communicationssystem 100 may be a multiple access system that provides content, suchas voice, data, video, messaging, broadcast, etc., to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 38, the communications system 100 may include wirelesstransmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a radioaccess network (RAN) 104, a core network 106, a public switchedtelephone network (PSTN) 108, the Internet 110, and other networks 112,though it will be appreciated that the disclosed embodiments contemplateany number of WTRUs, base stations, networks, and/or network elements.Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of deviceconfigured to operate and/or communicate in a wireless environment. Byway of example, the WTRUs 102 a, 102 b, 102 c, 102 d may be configuredto transmit and/or receive wireless signals and may include userequipment (UE), a mobile station, a fixed or mobile subscriber unit, apager, a cellular telephone, a personal digital assistant (PDA), asmartphone, a laptop, a netbook, a personal computer, a wireless sensor,consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the networks 112. By way of example, the base stations 114 a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, and the like. While the base stations 114 a, 114 b areeach depicted as a single element, it will be appreciated that the basestations 114 a, 114 b may include any number of interconnected basestations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, etc. The base station 114 a and/or the base station 114 b may beconfigured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in an embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. In anembodiment, the base station 114 a may employ multiple-input multipleoutput (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Theair interface 116 may be established using any suitable radio accesstechnology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as High-Speed Packet Access(HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed DownlinkPacket Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

In an embodiment, the base station 114 a and the WTRUs 102 a, 102 b, 102c may implement a radio technology such as Evolved UMTS TerrestrialRadio Access (E-UTRA), which may establish the air interface 116 usingLong Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 38 may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a campus, and the like. In anembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In an embodiment, the base station 114 b andthe WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yet anembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayutilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A,etc.) to establish a picocell or femtocell. As shown in FIG. 38, thebase station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 38, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks ownedand/or operated by other service providers. For example, the networks112 may include another core network connected to one or more RANs,which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 38 may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 39 is a system diagram of an example WTRU 102. As shown in FIG. 39,the WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad 128, non-removable memory 106, removable memory 132, apower source 134, a global positioning system (GPS) chipset 136, andother peripherals 138. It will be appreciated that the WTRU 102 mayinclude any sub-combination of the foregoing elements while remainingconsistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 39depicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in an embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In an embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. It will be appreciatedthat the transmit/receive element 122 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 39 as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in an embodiment, the WTRU 102 may includetwo or more transmit/receive elements 122 (e.g., multiple antennas) fortransmitting and receiving wireless signals over the air interface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 106 and/or the removable memory 132.The non-removable memory 106 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station (e.g., base stations 114 a, 114 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It will be appreciated that the WTRU 102 mayacquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

What is claimed:
 1. A method for verifying the trustworthiness of one ormore software or hardware components of a device, comprising: receivingfrom the device verification data generated by the device, wherein theverification data comprises at least a portion of a tree structureformed by the device, in which the roots of the tree structure containverification data from one or more secure registers of the device, innernodes of the tree structure are defined by a measurement log generatedby the device, and the leaves of the tree structure store integritymeasurement values from the measurement log generated by the device;comparing the at least a portion of the tree structure received from thedevice to a corresponding reference tree structure to determine whetherany of the received integrity measurement values match correspondingreference measurement values of the reference tree structure; andverifying the trustworthiness of the one or more software or hardwarecomponents of the device based on a result of the comparison.